Previously, `Instruction.toString()` returned the same string that is used in IR dumps, which requires numbering all instructions and generating a unique string for each instruction. This is too expensive on large snapshots. I've moved the original code into the new `Instruction.getDumpString()`, and made `Instruction.toString()` just return the opcode plus `getAST().toString()`.
This is motivated by test performance; IR compilation happens separately
for each test and takes a bit over a minute, so combining these 8 tests
saves about 10 minutes of test running.
The IR for the conversion to bool results in a comparison where the left
hand side is not the result of any expression in the AST, so they can't
be usefully converted back to the AST
After the recent inlining of `unresolveElement`, the join order in
`CommentedOutCode` became a problem. The join orderer was tempted to
join the two `hasLocationInfo` calls first because they had one column
in common. With this commit, they have no columns in common. It follows
from the other predicates in the same file that this column would be the
same, so there is no need to assert it in this predicate and risk that
the join orderer uses that information.
On Wireshark, the `CommentBlock::hasLocationInfo` predicate goes from
taking 2m2s to taking 180ms. The query produces the same 7,448 alerts.
The change to make `unresolveElement` a member predicate was helpful for
the optimiser when it dispatched on `this`, but now that it "dispatches"
on `result` it's just an unnecessary pollution of the `ElementBase`
namespace.
This change means that there are no results for `unresolveElement(t)`
where `t` is a "junk type" -- a class definition that is not in the
image of `resolveClass`. These "junk types" still exist as `Element`s,
but they will never be returned by any predicate that goes through
`unresolveElement` to query the db.
We get a small reduction in DIL size and a significant speed
improvement. The DIL for `NewArrayDeleteMismatch.ql` is reduced from
27,630 lines to 27,507 lines, and the total analysis time for the LGTM
suite on jdk8u is reduced from 1158s to 984s.
