4 ms·

I want a faster computer so that Visual Studio/MSVC compiles the code I write faster. I don't need a faster computer so that the application I develop runs fast

I want a faster computer so that Visual Studio/MSVC compiles the code I write faster. I don't need a faster computer so that the application I develop runs faster. I'm already running an unoptomized debug build of our application which takes an order of magnitude of time longer to execute any given operation. I live in a world where I cannot make performance evaluations based on my benchmarks on my "normal" build- I have to switch to a release build and recompile everything in order to make performance determinations. This led to my first personal experience of "premature optimization is the root of all evil". I implemented a new feature, performance was completely fucking untenably awful, so I threaded it. Performance was still awful, but it was 7x better because I has 7 free cores (8 total cores) to play with. I thought great, I tested, I found the bottleneck, I bandwidthed the fuuuck out the bottleneck, problem solved. A few weeks later I was testing on a release build, and in the same feature, the aforementioned bottleneck was using roughly 5% of the total CPU usage. Because the optimizer just - fixed all the slow stuff. The bottleneck that I threaded the shit out of didn't contribute significantly to the total CPU usage of the release build, while it was 87.5% or whatever of the debug build. And in the release build, I'm pretty sure all the threading overhead I added took away any and all benefit. The thing I learned from that experience was to ignore all performance problems unless I observe them in a release build. If I had a faster computer, it would be significantly easier for me to switch back and forth between release and debug builds. And I would thus be able to observe performance problems easier. I imagine there's a significant divide between front end web development and desktop application development here.

iainmerrick 6y ago
Your general point is of course correct, but “roughly 5% of total CPU usage of the release build” is absolutely worth fixing! As long as you fix it in the release build, not the debug build. If you have a computer fast enough to do a release build quickly, it’s probably also fast enough to hide performance problems with the release build. There are other approaches that can work, like building in the cloud so you don’t need a huge fast PC for each developer, or doing partially-optimized builds that balance build time with runtime (and debuggability).
ensiferum 6y ago
Why would you use the debug build though? I routinely develop using release build only and only ever execute a debug build if I really have to drop into the debugger. U find that this gives me a better experience as it puts me closer to the actual end product in terms of UX and functionality in general. (I obviously still use things like asserts that are always built in even in my release build a so I don't skip on bug detection just because it's a release build)

iainmerrick 6y ago

Your general point is of course correct, but “roughly 5% of total CPU usage of the release build” is absolutely worth fixing! As long as you fix it in the release build, not the debug build. If you have a computer fast enough to do a release build quickly, it’s probably also fast enough to hide performance problems with the release build. There are other approaches that can work, like building in the cloud so you don’t need a huge fast PC for each developer, or doing partially-optimized builds that balance build time with runtime (and debuggability).

ensiferum 6y ago

Why would you use the debug build though? I routinely develop using release build only and only ever execute a debug build if I really have to drop into the debugger. U find that this gives me a better experience as it puts me closer to the actual end product in terms of UX and functionality in general. (I obviously still use things like asserts that are always built in even in my release build a so I don't skip on bug detection just because it's a release build)