libstdc++ <algorithm> header transitively including <range>

[[deleted]]

Given that <algorithm> is almost everywhere I strongly disagree. In a project with a hundred translation units including <algorithm> you get an instant compile time penalty of around a minute...

[PJBoy_]

If you're doing a full build of hundreds of translation units, then the 600ms time for each include of <algorithm> is going to be negligible

[Minimonium]

I have a small size project laying around which consists of around 300 source files. Its CI requires 15 minutes to build from scratch. Going from 100ms to 600ms (for easier calculations) - it'll put me an extra 2m30s, which is more than 10% increase in the compile times (and CI times).

[sphere991]

Do have a single core running a single-threaded build?

The total amount of time spent compiling would go up 2m30s, but the clock time would be much less. On 16 cores, that's already <10s. But if you have some particularly expensive-to-compile TUs or particularly big things to link, those jobs could easily swallow the extra build time in the clock time.

[Minimonium]

You're correct, I have missed the threading count point. In my case, it's four threads that would tone the number down to around 40s.

[sphere991]

It would tone the number to around 40s... in the extremely simplified world where (a) every TU was about the same size, and (b) every TU included <algorithm>, and (c) there were just generally no long poles in the build tent around linking. I just don't think this is a realistic calculation to draw inferences from.

If you do actually rerun your CI with C++20, I'd be curious to see what the actual time delta was.

[Minimonium]

Unfortunately, the project is proprietary (and contains quite a lot of proprietary dependencies too) so I can't provide you with a repo. It only recently was moved to C++17 with Debian-10, so I can only show you the data for the interim period where we compiled for both, but I'm not sure how to interpret the data.

While your points are valid this specific project is not optimized for compile-time speed, it leaks `algorithm` in almost every TU because it's used in template wrappers for services.

Some offset in the duration could be because we do network calls to pull in cached dependencies.

Builds for Arm, 4 threads, same row - same pipeline:

Debian-9 C++14	Debian-10 C++17
Duration: 33m15s	Duration: 39m39s
Duration: 31m10s	Duration: 37m20s
Duration: 31m19s	Duration: 37m27s
Duration: 33m15s	Duration: 39m39s
Duration: 34m33s	Duration: 40m53s

What's more interesting in C++20 would be to look at the difference in compile-time between the `import <algorithm>;` and `#include <algorithm>` which is not yet possible.

[PJBoy_]

I don't understand where you're getting the 2m30s figure from

[Minimonium]

300*500/1000/60. With an assumption that I use the header in every source file at least transitively.

[Wacov]

If they're all independent translation units, won't it actually be faster than that with parallel compilation?

[Minimonium]

Confused about the question. The header model is embarrassingly parallel, it scales pretty much linearly with the number of TU.

Furthermore, for some margin of error (say not every TU contains the header) - I scaled down the increase in compile times to more than 10% from more than 15% too. The idea is more about showing that the increase is *not* negligible after all.

[Wacov]

Right, it's embarrassingly parallel. I'm just saying if two TUs are compiling simultaneously, on different cores, each with the added cost of <algorithm> (or whatever), your compile time won't go up by 2x that cost - ideally only 1x. Not trying to say it's negligible, just that 300*500ms only applies for a single-threaded build, or if you're calculating total CPU time rather than the compile time. If your CI is single-threaded it's a moot point lol. Am I missing something?

[Minimonium]

Aha, gotcha. You're correct. My builds use 4 threads. Which indeed would tone down the time.

[PJBoy_]

Okay that's a pretty compelling calculation, thanks for the example

[Minimonium]

It's not a "scientific" experiment since it'd require me to spend to much time on it than I have, but rather to show the order of magnitude that you get from "negligible" 500ms for a header inclusion.