[leetcrew]

do you ever compile code? at work I have a machine with an i7-7700 (4C/8T), 32GB of RAM, and an SSD. it still takes about 45 minutes to do a full build of the project I work on, which can easily be triggered by modifying any of the important header files. if I had to do my job on your laptop from 2009, I'd never get anything done.

[rs23296008n1]

That is the choice of software tool. You are literally grinding through gigabytes of data. If your tool didn't require so much data processing it would be faster. This may or not be possible to improve by you. Often there are workarounds.

Case in point: a matrix library I used to use needed to a full row/column pass each time. We put a layer in between it and our code. Reduced lookups required by 30%. We were processing the same amount of data and getting the same results but requiring far less time. That layer also reduced memory requirements. Now we could process larger datasets faster with the same hardware. Thats just one example.

Your choice of CPU and other hardware isn't always the limiting factor. Even the language choice has an impact. Some languages/solutions require more data processing overhead than others to get the same final result.

Even the way your program's Makefile or module composition can have an effect on compiling performance. I remember the use of a code generator we included that meant it had to regenerate a massive amount of code each run due to its input files being changed. We improved it by a ridiculous amount simply by hashing its inputs and comparing the hashes prior to running the code generator. Simply not running that code generator each time meant we sped up the build significantly. 30 minute build times reduced by 5-10 minutes. Same hardware. And that was easily triggered by a trivial file change.

[leetcrew]

I understand your point, I think. c++ has an inefficient build system, and over time projects can end up with very suboptimal build systems. it's definitely worth spending time to pick the low-hanging fruit like in your example, or if possible, to choose a language that builds faster.

still, even twenty minutes is a long time to wait and see if your latest change actually works. in the foreseeable future, there will be complex projects that take a long time to build. you will eventually have to touch things that everything else depends on and recompile most of the code. people that work on these projects can always benefit from faster desktop-class hardware.

[pdimitar]

That's just picking the lowest hanging fruit which is quite common sense. Not to diminish your achievement but if tomorrow, say, I figure Rust's compiler is slow, there's nothing I can do [in the foreseeable future].

Having much better hardware in these cases helps you be actually productive and not twiddle your thumbs waiting for the compiler.

[billti]

Came here to say exactly this. I’m waiting for Amazon to deliver the new CPU cooler I ordered today so my i9-9900k can run flat out for longer when building, after I spent so much of yesterday waiting 20 mins for another build when my attempted fixed didn’t pan out. (Though probably more of a reflection on how painful C++ as a language is if you have to touch a common header file).

[leetcrew]

obviously the whole "textually including header files" model introduces a lot of overhead in compilation, but as I understand it, optimizations are inherently expensive. if you want to do stuff like inlining across module boundaries, full rebuilds are inevitable when you touch commonly used code. I think it's reasonable to expect that compiling optimized builds of complex code will always hunger for more compute power.

[qwerty456127]

No, indeed I don't. It has been a long time since I've started actively avoiding C and C++ because it takes too long time to compile. Nevertheless I used to compile reasonable amounts of C# until recently and it wasn't a problem. Nowadays I mostly use write-and-run scripting languages like Python and build-free vanilla JavaScript.