Optimize JS compiler caching for standard builds#27026
Merged
Merged
Conversation
brendandahl
commented
May 28, 2026
| # Sadly we have to skip the caching whenever we have user JS libraries. This is because | ||
| # these libraries can import arbitrary other JS files (either vis node's `import` or via #include) | ||
| if DEBUG or settings.BOOTSTRAPPING_STRUCT_INFO or config.FROZEN_CACHE or settings.JS_LIBRARIES: | ||
| has_user_libs = any(not lib.startswith(utils.path_from_root('src/')) for lib in settings.JS_LIBRARIES) |
Collaborator
Author
There was a problem hiding this comment.
Alternatively, we could stick system libs in a separate setting, but that seems like a bigger change.
sbc100
reviewed
May 28, 2026
sbc100
approved these changes
May 28, 2026
Linker system stubs, such as libpthread_stub.js, are dynamically appended to settings.JS_LIBRARIES for all standard C/C++ builds. Previously, the JS output cache check did not distinguish between these system stubs and user-defined JS libraries (passed via --js-library). As a result, standard builds always bypassed the compilation cache, triggering a Node.js compilation run on every invocation. Restrict the cache bypass condition to check only for user libraries (libraries located outside the Emscripten source tree). Standard compilations now successfully hit the JS output cache, decreasing baseline compilation wall clock time of a hello world C program by 52% (from 472 ms down to 282 ms). Add an integration test to validate JavaScript compilation caching (covering hits, misses, user library bypasses, and option-based cache entries).
Collaborator
|
It looks like this broke repeated runs of The second time it fails because it expects to see the warning generated during the processing. I think the solution here is the avoid cache if there are any warnings during generation... but I don't know of an easy way to do that. |
Collaborator
Author
|
I think we can capture stderr and replay it. I'll put up a pr soon. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linker system stubs, such as libpthread_stub.js, are dynamically appended to settings.JS_LIBRARIES for all standard C/C++ builds. Previously, the JS output cache check did not distinguish between these system stubs and user-defined JS libraries (passed via --js-library). As a result, standard builds always bypassed the compilation cache, triggering a Node.js compilation run on every invocation.
Restrict the cache bypass condition to check only for user libraries (libraries located outside the Emscripten source tree). Standard compilations now successfully hit the JS output cache, decreasing baseline compilation wall clock time of a hello world C program by 52% (from 472 ms down to 282 ms).
Add an integration test to validate JavaScript compilation caching (covering hits, misses, user library bypasses, and option-based cache entries).