I've stated this before, but on my ancient (12 year old) i7 a sufficiently complex C project (6000 lines, more or less) can completely compile in under a second.
I dunno how much under a second because my build process only reports durations in seconds.
When using vim with the autocomplete using clang, single file compilations can finish in between keystrokes.
Is there a 0 missing? 6k lines of C is on the lower end of things, especially given how verbose vanilla C can be for basic stuff...
No zero missing. Routines for dynamic arrays/vectors, hashmaps, strings, etc (i.e. the basic stuff) are already in precompiled libraries (*.so).
The programs (there were two) consisted of an agent that sat on a remote box gathering packet traces and listening for commands to start/stop/change expression for capture, and would store+forward that capture to a server, which saved the capture in a format wireshark was able to read.
6000 lines is about right for something of that complexity.
AST representation of 6k LoC could probably fit for the most of its part into the L3 cache of modern CPUs. C and C++ build process is mostly a memory-bound problem.
That's the entire build process, not just the compilation. This means that things in the build (copying files, building archives, linking, etc) get counted as well.
In C, certainly. A short program I wrote took under 1s to compile and about 2s to link.
In C++ this is not the case; compilation is very computationally expensive, with my experiments in Rust leaving me with the feeling that Rust was even more computationally expensive than C++.
As someone who still regularly does C for fun and for profit, I am often left feeling frustrated when trying to compile projects in languages like C++ or Rust.
As an aside, some of the Lisp compilers (SBCL comes to mind) where much faster than one would expect, even though feature-wise it is more or less complete. It's the (I feel) typing and rules checking in complex languages that slows down the compilation, not the linking after everything is compiled.
A full debug build from scratch (with sanitizers and static analysis turned off) of one of my games (including my homemade engine) takes about 1.8s on my 6 years old i7-8565U - measured with `time ninja`. That's about 10k lines of code.
It goes up to 6s when I enable ImGui integration, as ImGui is written in C++.
When I build it with an embedded copy of entire Allegro 5 library, it goes up to 13s.
A fully optimized complete build including both ImGui and Allegro takes 25s. cloc reports 325k lines of code.
During development, most of the time you just compile one unit incrementally, which boils it down to milliseconds either way, so that's probably the figure that's most relevant to your question (although clang-tidy can push it back to a few seconds).
Comments
I wish they'd given a number. 1s?
I've stated this before, but on my ancient (12 year old) i7 a sufficiently complex C project (6000 lines, more or less) can completely compile in under a second.
I dunno how much under a second because my build process only reports durations in seconds.
When using vim with the autocomplete using clang, single file compilations can finish in between keystrokes.
Is there a 0 missing? 6k lines of C is on the lower end of things, especially given how verbose vanilla C can be for basic stuff...
No zero missing. Routines for dynamic arrays/vectors, hashmaps, strings, etc (i.e. the basic stuff) are already in precompiled libraries (*.so).
The programs (there were two) consisted of an agent that sat on a remote box gathering packet traces and listening for commands to start/stop/change expression for capture, and would store+forward that capture to a server, which saved the capture in a format wireshark was able to read.
6000 lines is about right for something of that complexity.
AST representation of 6k LoC could probably fit for the most of its part into the L3 cache of modern CPUs. C and C++ build process is mostly a memory-bound problem.
Use the time command when running make.
That's the entire build process, not just the compilation. This means that things in the build (copying files, building archives, linking, etc) get counted as well.
Linking tends to be the slow part, right?
Especially for rust and c++.
From an iteration speed perspective, you’d want to time the whole build process, not just specially compilation.
In C, certainly. A short program I wrote took under 1s to compile and about 2s to link.
In C++ this is not the case; compilation is very computationally expensive, with my experiments in Rust leaving me with the feeling that Rust was even more computationally expensive than C++.
As someone who still regularly does C for fun and for profit, I am often left feeling frustrated when trying to compile projects in languages like C++ or Rust.
As an aside, some of the Lisp compilers (SBCL comes to mind) where much faster than one would expect, even though feature-wise it is more or less complete. It's the (I feel) typing and rules checking in complex languages that slows down the compilation, not the linking after everything is compiled.
This could speed up linking:
https://github.com/rui314/mold
A full debug build from scratch (with sanitizers and static analysis turned off) of one of my games (including my homemade engine) takes about 1.8s on my 6 years old i7-8565U - measured with `time ninja`. That's about 10k lines of code.
It goes up to 6s when I enable ImGui integration, as ImGui is written in C++.
When I build it with an embedded copy of entire Allegro 5 library, it goes up to 13s.
A fully optimized complete build including both ImGui and Allegro takes 25s. cloc reports 325k lines of code.
During development, most of the time you just compile one unit incrementally, which boils it down to milliseconds either way, so that's probably the figure that's most relevant to your question (although clang-tidy can push it back to a few seconds).