3 ms·

> I feel like if you close with "only 20% slower than make" you can't justify the title "is not slow." IIUC, the 20% slowdown happens with a build that does no

> I feel like if you close with "only 20% slower than make" you can't justify the title "is not slow." IIUC, the 20% slowdown happens with a build that does nothing, it's just the scons overhead. (Not sure if they replaced the compiler invocations with echo, or if they touched the result files right from Python, for this number. They mentioned both, but I don't remember which one of them resulted in the 20% figure.) The 20% figure should go down for real world builds.

aseipp 6y ago
Unless I'm misreading your description though, the problem is that "a build that does nothing", or "a build that does very little" is absolutely a real world build, because it's almost exactly what happens when you do incremental recompilation. It's one of the most common cases you would encounter.
- bb88 6y ago
  Sure, but re-linking was the big factor, or god forbid you touched a header file that was used in 400 code units -- or your ccache corrupted itself, or you changed your compiler flags (which would force ccache to recompile everything anyway). As much as I don't like programming golang, they did get compilation right. And Scons/ninja/automake/cmake issues just went away.
  - barumi 6y ago
    > or god forbid you touched a header file that was used in 400 code units In C/C++ that means you decided to change 400 translation units. That's not a problem with the build system at all. That's a problem with how the developers working on the project failed to follow basic best-practices in software development. No build system saves you from the mess you create yourself.
Ace17 6y ago
> IIUC, the 20% slowdown happens with a build that does nothing, it's just the scons overhead. That's the whole point of performance measurement for build systems. The overhead is precisely what counts here. If you have many source files to recompile, the fraction of time spent in the build system itself is going to quickly drop to almost zero : build-system stuff is generally several orders of magnitude faster than compiler stuff. So it would make little sense to compare build-system performance on full builds.

aseipp 6y ago

Unless I'm misreading your description though, the problem is that "a build that does nothing", or "a build that does very little" is absolutely a real world build, because it's almost exactly what happens when you do incremental recompilation. It's one of the most common cases you would encounter.

bb88 6y ago
Sure, but re-linking was the big factor, or god forbid you touched a header file that was used in 400 code units -- or your ccache corrupted itself, or you changed your compiler flags (which would force ccache to recompile everything anyway). As much as I don't like programming golang, they did get compilation right. And Scons/ninja/automake/cmake issues just went away.
- barumi 6y ago
  > or god forbid you touched a header file that was used in 400 code units In C/C++ that means you decided to change 400 translation units. That's not a problem with the build system at all. That's a problem with how the developers working on the project failed to follow basic best-practices in software development. No build system saves you from the mess you create yourself.

Ace17 6y ago

> IIUC, the 20% slowdown happens with a build that does nothing, it's just the scons overhead. That's the whole point of performance measurement for build systems. The overhead is precisely what counts here. If you have many source files to recompile, the fraction of time spent in the build system itself is going to quickly drop to almost zero : build-system stuff is generally several orders of magnitude faster than compiler stuff. So it would make little sense to compare build-system performance on full builds.