Skip to content

Conversation

erik-krogh
Copy link
Contributor

@erik-krogh erik-krogh commented May 11, 2020

I tried to figure out the performance regression in #3391, and that lead me to find some completely unrelated performance improvements. Which is why I'm opening a separate PR for these performance improvements.

8716790 and f8de691 helps reduce the impact of #3391, and 6d05b40 just improves performance in general.

An evaluation on nightly shows about 5% performance improvement.
(A redo of the all the regressions, and yet another redo of just the worst offender).

I have confirmed that each commit on its own improve performance, although the main impact seems to come from 6d05b40.
Here is an evaluation where master is compared first with just 6d05b40 and with all 3 commits together: link (in a sheet because formatting got weird in the report).

6d05b40 can cause some single queries to be slower, as it forces the cached ReachableBasicBlock::strictlyDominates predicate to be evaluated, and the query might not have needed that predicate without my change.
But as strictlyDominates is a cached predicate, that performance penalty completely disappears when running many queries.

TODO:

  • Big-apps evaluation

@erik-krogh erik-krogh added JS Awaiting evaluation Do not merge yet, this PR is waiting for an evaluation to finish labels May 11, 2020
@erik-krogh erik-krogh requested a review from a team as a code owner May 11, 2020 12:33
@asgerf
Copy link
Contributor

asgerf commented May 11, 2020

Neat! I'd say these changes looked sensible even without the performance boost 👍

@@ -71,8 +71,7 @@ module InclusionTest {
count(this.getACallee()) = 1 and
count(callee.getAReturnedExpr()) = 1 and
not this.isImprecise() and
inner.getContainerNode().getALocalSource().getEnclosingExpr() = callee.getAParameter() and
inner.getContainedNode().getALocalSource().getEnclosingExpr() = callee.getAParameter()
inner.getContainerNode().getALocalSource() = DataFlow::parameterNode(callee.getAParameter())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not understand this change.
The previous version used both getContainedNode and getContainerNode.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, that was a mistake from my end, I didn't notice the Contained/Container.

Everything ends up working anyway, as getContainedNode is called all the places the InclusionTest is used. And thus the getContainedNode constraint still enforced, just not in the CharPred.

I fixed it anyway (and refactored two other getEnclosingExpr()).

@esbena
Copy link
Contributor

esbena commented May 12, 2020

Great. We are just waiting for the evaluation then.

@erik-krogh
Copy link
Contributor Author

A big-apps evaluation looks very good.

All evaluations were without the latest change to IndirectInclusionTest, so I did a smoke-test on just the changes to IndirectInclusionTest, and that looks fine.

I think this is ready to land.

@erik-krogh erik-krogh removed the Awaiting evaluation Do not merge yet, this PR is waiting for an evaluation to finish label May 12, 2020
@semmle-qlci semmle-qlci merged commit ee84832 into github:master May 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants