Potential of a compiler that creates the executable at once

rempas rempas at tutanota.com
Fri Feb 11 12:25:39 UTC 2022


On Thursday, 10 February 2022 at 11:54:59 UTC, bauss wrote:
>
> You see, there's a large misconception here.
>
> Typically slow compile times aren't due to the LoC a project 
> has, but rather what happens during the compilation.
>
> Ex. template instantiation, functions executed at ctfe, 
> preprocessing, optimization etc.
>
> I've seen projects with only a couple thousand lines of code 
> compile slower than projects with hundreds of thousands of 
> lines of code.

Yeah, Of course! There is no misconception here. Templates play a 
role. When talking about LoC/s I'm talking about clear lines and 
this is why I made it clear that in my example with TCC, I didn't 
used any preprocessors hence the 4M LoC were exactly 4.

> Generally most compiles can read large source files and parse 
> their tokens etc. really fast, it's usually what happens 
> afterwards that are the bottleneck.
>
> Say if you have a project that is compiling very slow, usually 
> you won't start out by cutting the amount of lines you have, 
> because that's often not as easy or even possible, but rather 
> you profile where the compiler is spending most of its time and 
> then you attempt to resolve it, ex. perhaps you're running 
> nested loops that are unnecessary etc. at compile-time and so 
> on.

Of course, the backed is what matters. TCC goes from source file 
to object file directly. GCC/D/Rust etc. Go from source file, to 
IR (maybe DMD doesn't but LDC, GDC do), then Assembly and then 
object file so this takes many times more than if you did it 
directly. But even then, TCC/Vox are many more times faster so 
still there is something more. Idk...


More information about the Digitalmars-d mailing list