Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support "Release, with symbols" mode #571

Closed
mcclure opened this issue Jul 11, 2023 · 1 comment
Closed

Support "Release, with symbols" mode #571

mcclure opened this issue Jul 11, 2023 · 1 comment

Comments

@mcclure
Copy link

mcclure commented Jul 11, 2023

I am using trunk to create wasm builds. I care a lot about the size of my emitted binary, so I am using the tool Twiggy to determine what functions/crates are contributing most to my binary size. A problem with Twiggy is it really needs symbol names to be useful. Without symbol names it can tell you that, say, a particular function is 16% of your binary size, but the function name is just a long hex number so this isn't actionable.

Trunk has previously added support for symbols in debug mode. However when testing for size debug mode becomes problematic. Debug/Release mode has an order-of-magnitude difference on file size (like, a 300k binary becomes a 2.6MB binary) and I worry that that size profiling on debug might be systematically misleading (for example what if a function is 16% of the binary in debug mode but only 2% with inlining from release mode or whatever).

Some buildsystems have an option where they build in release mode but with symbols included. Could Trunk add a version of this? (Building in release mode with symbols emitted as a separate file might also be as useful or more useful, but I don't know if this is possible in wasm or if twiggy would need changes to support it.)

@mcclure
Copy link
Author

mcclure commented Jul 11, 2023

Wait, I'm sorry, trunk already has this capability and decides whether or not to include symbols based on the presence or absence of "strip=" in the Cargo.toml (the correct approach imo).

@mcclure mcclure closed this as completed Jul 11, 2023
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

No branches or pull requests

1 participant