Huge performance boost in latest emscripten

[Mintyboi]

Recently, I upgraded my emscripten toolchain from 3.1.16 to 3.1.41 and to my pleasant surprise, I experienced a performance boost of around 33% in my application!
I understand without profiling results, and without knowing which part improves, I'm just shooting from my hips, but I thought I'd check with you guys to understand if there has been any known changes which may have improved the performance

[brendandahl]

If you have time you could try to narrow down what caused the boost by bisecting.

[wenhanchong]

Following up from @Mintyboi, we did some investigation and found that the performance boost came from a change in 3.1.22 where -fno-inline-functions is no longer passed to clang when using -Os. Our app has been using -Os because we prioritized startup speed and preferred to keep the wasm binary size small. We did some measurements and saw a degradation in startup speed, which was expected, but was more concerned when we saw that the increase in size of javascript file generated by 3.1.41 was 9x larger than the one generated by 3.1.16 (10.8MB vs 1.2MB). This PR #18540 in particular changed the scope of functions to be included in DEFAULT_LIBRARY_FUNCS_TO_INCLUDE, which bloated the size of our js file. The abstract did not mention a change in scope of included functions, and our app worked fine when we manually reverted the change to DEFAULT_LIBRARY_FUNCS_TO_INCLUDE. Is the increase in js file size expected? @sbc100

[sbc100]

#18540 was not indented to increase code size. Can you explain a little more how #18540 impacted you code size? I assume you using dynamic linking that PR is mostly targeted at that use case? Can you open a new issue for this? Can you share the full link command you using? Are you adding to DEFAULT_LIBRARY_FUNCS_TO_INCLUDE on the command line or is it just internal usage? Are you expecting functions DEFAULT_LIBRARY_FUNCS_TO_INCLUDE to be removed from output JS file somehow? (All this can be included in the new bug report)