PPS: closure linker setting is actually "--closure 1". On Wednesday, 18 January 2023 at 11:40:34 UTC+1 Floh wrote:
> PS: if you don't allocate/free with very high frequency, also consider > switching to the minimal Emscripten allocator with "-s MALLOC='emmalloc'" > > On Wednesday, 18 January 2023 at 11:36:26 UTC+1 Floh wrote: > >> Are you building will all optimization options turned to 11? Usually >> Emscripten is very good at aggressive dead code elimination, both on the >> WASM and JS side. Some things to check in the build settings to minimize >> build size (I'm not 100% sure how many of those are still needed versus >> having become the default now): >> >> - turn off filesystem support if you don't need it: -s NO_FILESYSTEM=1 >> (linker setting) >> - enabling LTO may help with more aggressive DCE, but also causes more >> aggressive inlining: -flto (compile and linker setting) >> - enable the Closure JS minifier: --closure (linker setting) >> - enable minimal runtime -s MINIMAL_RUNTIME=2 -s ENVIRONMENT=web >> - test the various optimization settings that trade off speed vs size >> (-O2 vs -Os vs -Oz) >> - use a minimal HTML shell file like this: >> https://github.com/floooh/sokol-samples/blob/master/webpage/shell.html >> >> Finally if you are looking for a more minimal GLFW/SDL replacement, check >> out sokol_app.h. This has fewer features than GLFW or SDL for desktop >> platforms, but is a fairly complete alternative for WASM applications: >> >> https://floooh.github.io/sokol-html5/ >> >> Cheers! >> On Monday, 16 January 2023 at 16:42:57 UTC+1 ulhas...@orbo.ai wrote: >> >>> Hello, >>> Need your help understaning how JS code is generated. >>> >>> In my project, I am using Emscripten to generate WASM. For window >>> management, I am using GLFW window. Application is working fine. >>> But generated JS code contains lot of unnecessary DOM manipulations and >>> event binding not used in application. >>> What I wanted is simple display-only canvas, but generated code is >>> handling lot of events I do not need. This also causing some leakage issues >>> in handlers. >>> >>> Is there any way I can get rid of this code? Some compilation options or >>> why it is present at first place? >>> >>> Any pointers would help. >>> >>> Thanks, >>> Ulhas >>> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/96dd0c1e-0d59-4b27-9e6a-777f09fd85ban%40googlegroups.com.
