Sujet : Re: Baby X is bor nagain
De : bc (at) *nospam* freeuk.com (bart)
Groupes : comp.lang.cDate : 21. Jun 2024, 14:25:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v53v0q$36coc$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : Mozilla Thunderbird
On 21/06/2024 11:46, David Brown wrote:
On 20/06/2024 22:31, Vir Campestris wrote:
On 17/06/2024 14:43, David Brown wrote:
>
Compilation speed is important to everyone. That's why so many tricks are used to get around the lack of speed in a big compiler, or so many extra resources are thrown at the problem.
>
What "tricks" ?
>
Precompiled headers sprang to mind in about half a second.
>
<https://en.wikipedia.org/wiki/Precompiled_header>
>
Andy
These are used primarily in C++, where you often have /very/ large headers that require a significant amount of analysis. In C, this is not remotely the same scale of problem. C headers are usually far shorter - and far simpler to process. (In a quick test on my system, #include <stdio.h> pulled in 792 lines, while #include <iostream> took 28152 lines.)
C standard headers are nothing. From 3K to 5K lines between Windows and Linux, last time I looked. That's for all 30 headers. (Which is why I think they should just be included anyway.)
But library headers can be much bigger. I already gave a timing for windows.h, of 1.4 seconds. SDL2, quite a small library compared with some, is still 50K lines, and adds 0.75 seconds compilation per module.
It's too big a job to test with GTK4, but GTK2, from my last experiments, was 350K lines across 550 unique header files, and involved processing over 1000 #include statements.
It was a test project earlier this year where multiple modules each including, indirectly, sdl.h, which cause a noticeable sluggishness in my mcc compiler.
If I was to take that product seriously, that is where I would strive to apply whole-program-compilation methods (developed for my main 'toy' compilers), so that a library like sdl.h is processed once at most if included by N modules in a specific mcc invocation.
If I set up a dummy test where there are 50 .c files each with '#include "sdl"' and one empty function, plus one main.c file, then a gcc build takes 36 seconds.
If I use a precompiled header for sdl.h, it takes 5-6 seconds (remember there is no application code; this is just the SDL interface).
When I set up the same test in my language, it takes 0.05 seconds. (This also uses a single interface file for SDL where its 75 C headers are summarised as a set of declarations totalling under 3000 lines.)
So 700 times faster than gcc processing header files, and still over 100 times faster when gcc employs its secret weapon: precompiled headers. Which you said are not necessary.
To summarise, in my test, a C compiler has to process 2.5M non-unique lines of declarations across 4000 non-unique header files. My compiler has to process only 3K unique lines in one unique file.
You will obviously dismiss my amateurish efforts out of hand, but they show what is possible, and what you need to look at if trying to speed things up.