Binaryen-related micro optimizations #8257
Open
+108
−68
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.
This should shave a couple seconds off
wasm-emscripten-finalize, which is really slow for me (more with source maps & stack overflow detection enabled, which I didn't look at here (yet)). Didn't make as much of a different as I'd hoped, but anyway.third_party/llvm-project/dwarf2yaml.cpp, since it comes from LLVM. I did also submitdwarf2yaml.cppoptimizations llvm/llvm-project#179048 but their version is very different, and not only in theXXX BINARYENareas.locationUpdater.has*()usages is correct. It seems that the result is almost identical. If the subtle difference is relevant, I can merge the two functions in a different way, wrapping inoptionalbut also allowing0if the old location was found but the new wasn't.Y.AbbrevDecls.reserveusing the loop is a bit overkill since I think the performace impact was minimal, I can remove it if you want.When built with
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_MIMALLOC=ON -DBYN_ENABLE_LTO=ON -DBUILD_STATIC_LIB=ON -DBYN_ENABLE_ASSERTIONS=OFF:Pre: 19s
Post: 16.5s