perf: strip release binaries to minimize size, but download debug info on panic to get useful stack traces #27811
+219
−51
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 saves about 26 MB on macOS, should be similar on linux (stripping makes no difference on windows because symbols are already in a separate file).
This PR strips symbols from the release binaries, but separates and uploads the debug info for debugging.
To make sure stack traces on panics are still useful, we lazily download the debug info when panicking (but only if running with
RUST_BACKTRACE
set). Since most users should not hit panics, this means that most people will get the benefits of smaller binary size with no drawbacks.An additional benefit is that now that debug info is separate, stack traces are actually more useful because we can included more detailed debug info without worrying about the binary size.
This also resolves an issue on windows where stack traces on panics are incorrect, as the symbol information is already separate but we don't distribute it.
Remaining questions / things to resolve:
ureq
for a simple synchronous http client, but maybe we could reuse our own client? just seemed tricky to do in a panic hook context