Java: Fix more performance issues with future versions of codeql.#6755
Java: Fix more performance issues with future versions of codeql.#6755aschackmull merged 3 commits intogithub:mainfrom
Conversation
|
The caching of params string, and the nomagic in
Note also, that the |
0fa9ecc to
447eb23
Compare
|
So with the magic, if within a stage for a call we pick no magic there is no magic ever. This means we simply need a single I ended not actually changing I have opened an issue about making it easier to prevent magic for tcs. |
It turns out that between writing the previous fixes and retesting, even more problems arose for java. I think java is more affected because
Reftypeis bigger thanClass, but most uses only needClassso trivial type tests affect java more than other langauges.List of changes:
AndroidComponentwere no longer good enough. Instead this forces the TC to be materialised rather than use the bad magic version (which was done repeatedly). I decided to do this viagetAnAncestorso I didn't have to define new predicates and as we evaluate the full TC we always want to use the non-magicked version after that. Note that only one use in each stage needs to be converted but asAndroidComponentwas top in the magic as it has the first name alphabetically. I have opened an internal issue about making doing this change easier.ConfusingOverloading.ql, the existing magic didn't help much so removing it seems better.