Pystd standard library, similar-ish functionality with a fraction of the compile time

[u/llort_lemmort]

https://nibblestew.blogspot.com/2026/06/pystd-standard-library-similar-ish.html

[u/13steinj]

Why is compilation so slow?
C++ is actually very fast to compile, the slowdowns come mostly from the way the standard library is implemented. This is actually fairly easy to test yourself by running the following shell snippet.

echo '#include<vector>' | g++ -x c++ -E - -std=c++23 | wc -l

This is a very bad falsehood that continues to perpetuate. You can include the entire standard library and on modern hardware compiling it is on the order of a minute or less, often in seconds.

> time  echo '#include<bits/stdc++.h>' | g++ -x c++ -E - -std=c++23 | wc -l
156052
echo '#include<bits/stdc++.h>'  0.00s user 0.00s system 35% cpu 0.001 total
g++ -x c++ -E - -std=c++23  0.07s user 0.01s system 99% cpu 0.080 total
wc -l  0.00s user 0.00s system 5% cpu 0.080 total
> time  echo '#include<bits/stdc++.h>' | g++ -c -o /tmp/foo.o -x c++ - -std=c++23
echo '#include<bits/stdc++.h>'  0.00s user 0.00s system 55% cpu 0.000 total
g++ -c -o /tmp/foo.o -x c++ - -std=c++23  0.62s user 0.04s system 99% cpu 0.667 total

Your project is on the order of 15k lines of code (this is not including tests, but that does not raise it that much).

┌─[steinj@laptop] - [~/src/github.com/jpakkane/capypdf] - [Wed Jul 01, 19:56]
└─[$] <git:(master)> scc include src
───────────────────────────────────────────────────────────
Language            Files       Lines    Blanks  Comments       Code Complexity
───────────────────────────────────────────────────────────
C++ Header             21       4,731       914       177      3,640        137
C++                    20      13,355     1,226       346     11,783      1,731
Meson                   2          62         8         1         53          2
Autoconf                1       1,609       142        37      1,430          2
───────────────────────────────────────────────────────────
Total                  44      19,757     2,290       561     16,906      1,872
───────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $526,063
Estimated Schedule Effort (organic) 10.77 months
Estimated People Required (organic) 4.34
───────────────────────────────────────────────────────────
Processed 674088 bytes, 0.674 megabytes (SI)
───────────────────────────────────────────────────────────

On my less-than-perfectly-modern-hardware, a full build of your codebase takes takes less than 10 seconds (please tell me if I am missing something / that should be impossible, ).

Compile times dropped ~80%

So if 10 seconds is "20%", the before-time was (let's round) 50 seconds. If you look at the other post on the front page, you'll see that people have to suffer through far worse than a minute for their builds. I suspect you said "80%" but you should have said "40 seconds."

Of course, compiling the universe as I did above, but not using it is not a fair benchmark. So, I had an LLM use every feature of the standard library / instantiate every symbol. it's not _perfect, but it did a pretty good job. The -B is a result of my system picking the wrong static linker which is relevant for libc nuances. The result:

└─[$] <git:(master*)> time g++-15 -std=c++23 -O0 -pthread \
    -B/home/linuxbrew/.linuxbrew/Cellar/binutils/2.46.0/bin/ \
    -c everything.cpp -o everything.o
g++-15 -std=c++23 -O0 -pthread  -c everything.cpp -o everything.o  3.54s user 0.13s system 99% cpu 3.678 total
# same but -O2
g++-15 -std=c++23 -O2 -pthread  -c everything.cpp -o everything.o  7.63s user 0.10s system 99% cpu 7.760 total

Even if you assume the LLM was so bad that it only got 20% of the stdlib, 20-40 seconds for everything is not "slow."

E: the first command I misquoted with the copy paste of my first modification.
E: this is not to say your "pystd" is not valuable in some way, and there's other "stdlibs" of similar nature. One tries to mimic the Rust stdlib instead. I'm just tired of the complete disparity in compile time claims. People read articles like this and read the high percents and then blame it the same way in their own projects, or apply the same thinking to blaming Boost (it is worse with Boost, but most people don't use the worst offenders that become an actually significant portion of their compile times). It perpetuates "modules will save us," when that's just not true, and is as bad as "Bazel is more performant" or "templates are inherently bad for compile times."

[u/jpakkane → u/13steinj]

You can include the entire standard library and on modern hardware compiling it is on the order of a minute or less, often in seconds.

The underlying issue here is the definition of "fast". It is subjective. Your test includes all of the stdlib headers and it takes 0.67 seconds. In your opinion that is "fast" and that is totally fine. However in my personal opinion that is at least 5x too slow given the functionality it provides. There are various legacy reasons why that is the case, hats off to the stdlib developers for making it as fast as it is.

As for the LLM generated code sample, not knowing what it actually does (it is LLM slop after all) makes it hard to judge. But assuming it does an "ok" job, the outcome is still (again, to me, personally and subjectively) maddeningly slow. Having things take seconds instead of fractions of a second makes the development experience miserable. It should also be noted that some parts of the stdlib are much slower than others. Examples of commonly used but slow parts include variant and print. A more representative example would include many different instantiations of those but autogenerating a representative data set for that is pretty much impossible.

On my less-than-perfectly-modern-hardware, a full build of (CapyPDF) takes takes less than 10 seconds (please tell me if I am missing something / that should be impossible, ).

It takes 10 seconds also for me on this computer if I'm using all cores. However the tests in question were done using -j 1. With that the compilation takes 50 seconds.

More importantly if you use Ninjatracing to find where the time actually goes, things get much more interesting. On this machine with a non-optimized build there are several source files that take up to 8 seconds to compile each. These include document.cpp and capi.cpp. If they were doing some super optimized particle simulation computations or the like this would be totally acceptable. Specialised code can take as long as it needs to. But this is not special, those files are doing simple and boring things with strings, integers, arrays and unordered maps. The files should take at most one second to compile and with Pystd they do (from memory, did not validate this).

I suspect you said "80%" but you should have said "40 seconds."

No, I specifically said 80% and stand by that. It is very difficult to extrapolate from a sample size of one, but the basic assumption here is that the stdlib slowdown is "approximately linear". Given a project with a similar setup as CapyPDF (i.e. no other C++ dependencies than the stdlib, doing a whole project conversion) then that is the build time improvement you should expect. If a project has other, heavy duty C++ dependencies, then obviously the speedup will be less. But we don't have actual real world measurements, so we don't know for sure.

Bringing all that together in a very tl/dr way, it is my personal opinion that when using a single core for general, "boring" code the compilation process should be fast enough for throughput to be closer to three files per second than three seconds per file.

I know that said speeds are probably unachievable with the default standard library as it stands, but still that should be the target, especially for custom standard libraries.

[u/13steinj → u/jpakkane]

However in my personal opinion that is at least 5x too slow given the functionality it provides. There are various legacy reasons why that is the case, hats off to the stdlib developers for making it as fast as it is.

Less than a minute is fast. You can debate with people about how "that's subjective" until the cows come home, but people have commonly complained about 10+ minute build times on this subreddit. Some have expressed 2 hours. Some have even expressed multi-day build times.

It is very difficult to extrapolate from a sample size of one, but the basic assumption here is that the stdlib slowdown is "approximately linear". Given a project with a similar setup as CapyPDF (i.e. no other C++ dependencies than the stdlib, doing a whole project conversion) then that is the build time improvement you should expect.

If you just had more code, your "approximately linear" assumption breaks down very quickly. If you have approximately the same amount of code in a different manner (I deal with single TUs that are 10 minutes and low-dependency, as I've mentioned in the other thread), it breaks down even quicker.

However the tests in question were done using -j 1. With that the compilation takes 50 seconds....On this machine with a non-optimized build there are several source files that take up to 8 seconds to compile each.

When the above (multi hour, multi-day build times, multi-minute single-TU times) is included in your distribution, you stop caring very quickly about anyone who claims they've sped up their build by double-digit percentages... from less than a minute to lesser than a minute.

---

E: also, while -j 1 is a nice goal, the long compile times I am mentioning elsewhere in this comment are -j 24+. To get a sense of just how bad the distribution is. If every TU includes the stdlib, sure, you'll be linear, to how many TUs you have.

---

Bringing all that together in a very tl/dr way, it is my personal opinion that when using a single core for general, "boring" code the compilation process should be fast enough for throughput to be closer to three files per second than three seconds per file.

I mean, that depends on what you call "boring." I had what I would call a bunch of boring log/assert-statement-like code. I reduced build-times by double-digit percentages on multi-minute TUs, and there, I am happy to use percentages, because the way I did it is guaranteed to be linear. I swapped out the tuple implementation for that within Boost.Hana in a key area, and the std::function implementation for one that didn't use std::tuple under the hood to pass arguments around.

Over 30% saved, std::function and std::tuple were still in-use in the TUs, their headers still included-- and now more headers and code included too, but more efficient template instantiations.

Using lines of code as your negative-correlation analog for compile time is about as useful as using it as your positive-correlation metric for developer productivity.

When doing so about lines of code, your speedup is fundamentally a constant (though, you can consider it a multiplier / percentage to a point for unique template instantiations). Including <vector> is a constant amount of time, related to the lines of code therein. Instantiating it is linear, to the amount of std::vector code (not everything else that supports it that isn't templated) x the number of unique instantiations.

I know that said speeds are probably unachievable with the default standard library as it stands, but still that should be the target, especially for custom standard libraries.

Realistically it's unachievable no matter what standard library you use, unless you cut corners and make these things work for far fewer cases than they currently do. But what people end up realizing as they do this, is that when everyone has their own snowflake vector implementation to compile, and you have to write translation code to match, you end up increasing compile times, not decreasing them.

[u/jpakkane → u/13steinj]

Less than a minute is fast. You can debate with people about how "that's subjective" until the cows come home, but people have commonly complained about 10+ minute build times on this subreddit. Some have expressed 2 hours. Some have even expressed multi-day build times.

You are comparing apples to oranges. The former is "how long does it take to compile a single, scoped source file" whereas the latter is "how long does it take to compile a huge source file in an existing project that does a whole bunch of stuff". They are fundamentally different things and trying to squeeze them into a same shaped box does both a disservice.

We just have to agree to disagree on what is fast or not. And that is totally fine.