Skip to content

Memoize JsInliner.containsNestedFunctions - #10397

Open
rhuanhianc wants to merge 2 commits into
gwtproject:mainfrom
rhuanhianc:perf/jsinliner-memoize-nested-functions
Open

Memoize JsInliner.containsNestedFunctions#10397
rhuanhianc wants to merge 2 commits into
gwtproject:mainfrom
rhuanhianc:perf/jsinliner-memoize-nested-functions

Conversation

@rhuanhianc

Copy link
Copy Markdown

containsNestedFunctions is a pure function of a function's body, but it is recomputed — a full traversal of the entire body — once per candidate call site, on every inliner pass. On a large application, JFR sampling attributes about 79% of all JsInliner time to this single predicate, and JsInliner itself accounts for 28.7% of the permutation's CPU.

This memoizes it in a thread-local IdentityHashMap, cleared at the start of each execImpl so it never outlives a single run of this optimizer, and invalidated per function wherever the inliner rewrites that function's body.

Invalidation happens at both points where a body actually changes: inprocess()when an inline is committed, and again right after ctx.replaceMe(op). The second is necessary because the intervening op = accept(op) can re-populate the memo for the caller while op is still detached from the tree.

endVisit(JsExprStmt) also mutates bodies, but only by removing or restructuring content already present in that statement, so it can only take the answer from true to false. That is the conservative direction: a stale true leaves safeScope null and makes the inliner more cautious, never less.

Measured on two real applications, JsInliner drops from 57.9s to 10.5s and from 328.5s to 22.8s. Generated JavaScript is byte-for-byte identical across 874 output files from four applications, including two built with two permutations (4 and 20 local workers). ant -Dtarget=test dev passes: 1936 tests, 0 failures.

Fixes #10394

The predicate only depends on the function body, but it was recomputed by
traversing that whole body once per candidate call site, on every inliner
pass. Profiling a large application attributes about 79% of JsInliner's time
to it.

Cache it per function, dropping the entry wherever the inliner rewrites a
body. On two applications JsInliner goes from 57.9s to 10.5s and from 328.5s
to 22.8s, with byte-identical output.
* Examine a JsFunction to determine if it contains nested functions.
*/
private static boolean containsNestedFunctions(JsFunction func) {
Boolean cached = containsNestedFunctionsCache.get().get(func);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

You can use computeIfAbsent here.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Thanks, updated to use computeIfAbsent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JsInliner re-traverses whole function bodies once per call site

2 participants