> Is what you're saying is that those compilations are fast enough? You wouldn't want it to take 1 or 3 seconds and see no reason why it should?
In most practical cases (incremental rebuild) it does take 1-3 seconds. There is just not a huge amount of practical benefit to me. If one has interest in things taking 1-3 seconds for a full rebuild provided one has compiled the code before, there's ccache:
I had to install ccache (reason: this doesn't even cramp my workflow enough to bother until doing this benchmarking) and just do this:
env PATH=/usr/lib/ccache:$PATH time make -sj10
All of PostgreSQL successfully made. Ready to install.
6.05user 1.88system 0:02.48elapsed 319%CPU
If I don't cheat by using ccache, then turning off the optimizer gives me about 50% of my time back:
120.00user 11.72system 0:21.75elapsed 605%CPU
Here's the result of touching one c file in the executor and doing an incremental build (including linking):
0.74user 0.18system 0:00.68elapsed 137%CPU
A randomly chosen header file gives me about two seconds, with --enable-depend on:
3.33user 0.51system 0:01.53elapsed 249%CPU
I like Go, and appreciate that it compiles very quickly in some absolute sense, and for many other reasons, and do not wish for a hideous preprocessor system, but to me claims against the time it takes to compile a reasonably large C program are dubious enough that is can only lead to overzealous suspicion by parties that have to make a quick evaluation on what to spend their time with.
> they take 10-60 seconds for a 1 line change in a .cc file....
.cc is another kettle. Just as the disadvantages of .cc should not be lumped with .c, the opposite also has to be taken into careful consideration: some advantages of .cc are not available to .c, and some advantages of both are retained in .go.
Also, ./configure and Postgres's 'initdb'. Now that's slow, in spite of some efforts to speed up the latter.
In most practical cases (incremental rebuild) it does take 1-3 seconds. There is just not a huge amount of practical benefit to me. If one has interest in things taking 1-3 seconds for a full rebuild provided one has compiled the code before, there's ccache:
I had to install ccache (reason: this doesn't even cramp my workflow enough to bother until doing this benchmarking) and just do this:
If I don't cheat by using ccache, then turning off the optimizer gives me about 50% of my time back: Here's the result of touching one c file in the executor and doing an incremental build (including linking): A randomly chosen header file gives me about two seconds, with --enable-depend on: I like Go, and appreciate that it compiles very quickly in some absolute sense, and for many other reasons, and do not wish for a hideous preprocessor system, but to me claims against the time it takes to compile a reasonably large C program are dubious enough that is can only lead to overzealous suspicion by parties that have to make a quick evaluation on what to spend their time with.> they take 10-60 seconds for a 1 line change in a .cc file....
.cc is another kettle. Just as the disadvantages of .cc should not be lumped with .c, the opposite also has to be taken into careful consideration: some advantages of .cc are not available to .c, and some advantages of both are retained in .go.
Also, ./configure and Postgres's 'initdb'. Now that's slow, in spite of some efforts to speed up the latter.