Tested some recommendations from the Rust min-sized-guide to see how they affected binary size.
I think we should use LTO with codegen-units=1. It has a decent impact on the binary size, and we use it in quil-rs already for the performance.
I also don't see any harm in stripping symbols, but I could be convinced otherwise. I'm not sure if they'd ever be useful in practice, as we can just re-build with symbols from a buggy version if we really needed them and I don't think we'd expect users to want to load release wheels into a debugger.
Out of interest, I also tested -Oz and aborting on panics. These negatively impact performance and functionality, so they aren't good for our use case, but I was curious to see how much of an impact they had.
Results
Starting from main, I progressively added one option at a time and measured the resulting wheel, tracking their reduction from the previous step, and overall when compared to the binary generated by main.
I only built a wheel for my platform on Python 3.11, so mileage may vary for different Python versions and platforms. With that in mind, we can do some potentially irresponsible napkin math. If we take the 35.79% overall reduction from the approach I'm proposing in this PR, and extrapolate it to the 168MB size of all wheels in the last release, we'd reduce it down to 108MB.
closes #366
Tested some recommendations from the Rust min-sized-guide to see how they affected binary size.
I think we should use LTO with codegen-units=1. It has a decent impact on the binary size, and we use it in quil-rs already for the performance.
I also don't see any harm in stripping symbols, but I could be convinced otherwise. I'm not sure if they'd ever be useful in practice, as we can just re-build with symbols from a buggy version if we really needed them and I don't think we'd expect users to want to load release wheels into a debugger.
Out of interest, I also tested
-Oz
and aborting on panics. These negatively impact performance and functionality, so they aren't good for our use case, but I was curious to see how much of an impact they had.Results
Starting from main, I progressively added one option at a time and measured the resulting wheel, tracking their reduction from the previous step, and overall when compared to the binary generated by main.
I only built a wheel for my platform on Python 3.11, so mileage may vary for different Python versions and platforms. With that in mind, we can do some potentially irresponsible napkin math. If we take the 35.79% overall reduction from the approach I'm proposing in this PR, and extrapolate it to the 168MB size of all wheels in the last release, we'd reduce it down to 108MB.
For posterity, the wheel I was building: