Hacker News Reader

Comment by Hamuko | Hacker News Reader

>Cargo defaults its optimization level to 3 for release builds, which optimizes the binary for speed. To instruct Cargo to optimize for minimal binary size, use the z optimization level in Cargo.toml

In what scenarios is optimizing for binary size preferred over optimizing for speed?

View on HN

Sometimes a binary optimized for size is faster than one optimized for speed. (Due to cache residency, as mentioned in another comment.)

SQLite recommends optimizing for size, because it yields a significantly smaller binary with minimal speed impact: https://www.sqlite.org/footprint.html

Maybe Windows specific, but if you run an exe from a shared directory or removable drive then in some cases[1] Windows will copy the entire exe before running it.

In that case having a big exe file can really hurt start-up performance, so optimizing for that might be preferable if your application is not very speed sensitive.

[1]: https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-... (IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP)

if it makes the difference between fitting the whole binary in L1 cache or not, then the wins on memory latency could beat the losses on branch misprediction

>In what scenarios is optimizing for binary size preferred over optimizing for speed?

64kb intros:

https://www.reddit.com/r/rust/comments/597hhv/logicoma_elysi...

https://www.pouet.net/prod.php?which=69658

However, 8 kB (the binary size mentioned in the article) is still drastically too much overhead in a 64k intro, and 4k intros are obviously out of the question.

Any service or deamon that hardly takes any cpu time regardless of optimization.

In WebAssembly for example.

Embedded systems.

Embedded systems frequently have flash size limitations in the megabytes or even kilobytes.

When loading the larger binary from storage takes longer than the execution speed gain justifies.

Reply on news.ycombinator.com