3 ms·
Mostly because CPU caches matter a lot. Executing 7-8 different Rust binaries, in a loop, that are each north of 10MB+ is bound to be less performant than corre
by pdimitar 3y ago
Mostly because CPU caches matter a lot. Executing 7-8 different Rust binaries, in a loop, that are each north of 10MB+ is bound to be less performant than corresponding smaller programs.
Never had the time or dedication to actually verify this but I've been bitten by programs and OS-es that trash the cache too much and I've seen humanly perceivable lags because of it. But maybe in this case I am overreacting.
- nindalf 3y agoWould debug symbols ever be loaded into CPU cache? They'd be in RAM, sure. But why would the CPU ever load them into cache? The way I'm imagining this, and I could be wrong, is that the debug symbols are to one end of the binary. They wouldn't be loaded into cache unless they're going to be used imminently. Another way of saying this is that the change to strip automatically is a small win for for disk space and RAM consumption, but I don't think it's going to improve performance dramatically? I could be wrong about this though.
- pdimitar 3y agoNo, it's more likely that you are correct because it has been a long time since I worked that close to the metal and my info is outdated or downright wrong at this point. Thanks for the nuance. If debug symbols indeed never go into the CPU cache then my remark is completely irrelevant.
- kramerger 3y agoI think most debug info is in its own section. On a real OS the pages are loaded lazily so no (significant) performance hit. Still, I hate big Rust binaries as much as the next guy.