apparently Inkwell can strip debug symbols.
It seems reasonable to do this by default for --optimize builds, since we're optimizing and a smaller executable will run faster (all else being equal).
We could also add an optional --debug-symbols flag to keep them in.
Thoughts?
agreed people are likely to strip the symbols otherwise anyway
Do we even emit much? I feel like our default debug info is super lacking
Not saying we won't save a few bytes
it's a surprisingly big difference for Rust hosts!
the 3 demos I'm looking at for Tuesday, without symbols and with symbols:
That is probably host debug info? Not roc?
So inkwell doesn't affect them?
fair point!
Hello World with different hosts:
actually all of this is probably dominated by the fact that I'm on mac, where ld doesn't support --gc-sections :stuck_out_tongue:
(although it does have the theoretically equivalent -dead_strip, except that I just found out it can't be used with the -r flag we give to ld)
so I guess in a future where we have a surgical linker, we can tell hosts to --gc-sections when making the executable, which theoretically should be fine as long as they have the right things marked as exposed and therefore ineligible for collection...or alternatively we can potentially do it ourselves in the surgical linker
For sure. Though doing GC on the host would probably be a hassle in the surgical linker. Doing GC on the app should be just fine though.
Yep, can confirm it's hassle! But I actually did it in the wasm backend, because without it the tests were just unbearably slow. Had to do it for my own sanity. Wasmer is orders of magnitude slower than v8.
So I keep track of which builtins and host functions the app actually uses, then trace through their call graphs in a "mark" phase, then do a "sweep" phase to remove them.
Though I don't strip debug symbols. I figure if you are using a dev backend then you probably want them.
Stack traces and stuff are terrible without them
Last updated: Jun 16 2026 at 16:19 UTC