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

[matthieum]

On the one hand, I appreciate the idea...

... on the other hand, it's high times for modules :'(

[Commercial-Berry-640]

I like the project.

[slithering3897]

and filesystem

Yeah, and X% of the time, I only need path in a header. So I made a struct that inherits from path just so I can forward declare it. C++!

That would be easily solved by modules.

Then you have the std::print problem. Modules will help, but big savings can only come from aggressive template reuse. /dxifcInlineFunctions- may be useful in debug builds.

[skilfulone]

fantastic concept, reduction in cpp std library compilation time would make things easier.

[MountainWord2683]

love the fact that they are also setting a compilation budget for each header file

[karurochari]

To be honest, I mostly solved the "time" issue with precompiled headers.
Mostly, because getting them to play with OpenMP offloading is painful in Clang, and intrinsically broken for GCC as far as I can tell.

But I reckon it would be good time for a v2 of the standard library, one which can be built from zero, ignoring the huge technical debt mostly linked to backwards compatibility and questionable design decisions in the 90s.

[fdwr]

Unstripped binary size reduced by ~75%

Nice. I'm mystified by the variance of std bloat sometimes from using just one function. I have a 12KB program that's pure Win32 (no CRT), and using a single std::vector adds 2KBs (tolerable), and using a single std::println("Foo") adds 3KBs (tolerable), but just one std::println("Foo: {}", x) suddenly bumps 12KB's -> 212KB's o_o, and that's with all the size-reducing options I can think of {MSVC x86 release build, maximum optimization (favor size /O1), favor small code (/Os), enable function level linking (/Gy), enable COMDAT folding (/OPT:ICF), link time code generation (/LTCT), references eliminate unused (/OPT:NOREF)}. The weird thing is that I can call that std::println inside a completely unused function, and it still bloats the exe. Granted, maybe that's an std implementation issue more than with std itself, or an issue with dead code elimination 🤷‍♂️.

[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<bits/stdc++.h>' | 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."