Delphi used to compile 200k lines in less than ten seconds. That was around year 2000, with first generation Pentium. Later it slowed down a bit, but not so much.

IIRC, C family compilers suffer from some problem with headers that makes compile time much longer than it should.

Edit: oh, and that was rebuilding the whole program from scratch, including all libraries. A little change in the current file was les than one sec. Native code, in case you're wondering.

Anything written in interpreted languages like Javascript/Typescript. UI stuff usually has hot reloading where you get "compilation" times measured in milliseconds, and from experience restarting even a complex typescript server is a few seconds max. This applies to mobile apps as well when using React Native.

What about Gulp, NPM, Yarn etc. running in the new build of UI stuff? Those take up a bunch of time.

I don't quite get your point. Your parent was pointing out that there are interesting projects where the "compile" time is milliseconds — at least for the developer perspective. It doesn't really matter that there's a step later in the pipeline at takes longer, so long as it's not in your way. Also, most of that could be cached away anyways.

Those are all earlier in the pipeline, required for the project to run, and gulp doesn't cache (or, didn't back when we used it), which IMO was the main reason webpack beat it so quickly.

I worked hard on my previous project to achieve a 5sec build-run-test cycle for a medium-sized embedded C project (we don't have monster workstations, just some i7-10xxx/16GiB PCs).

Thinking about proper modularization, runtime code (hot-re)loading, and eliminating single-point-of-recompilation for header files goes a long way.

The gamedev industry figured this out a long time ago, see Handmade Hero's Hot reloading[0].

Also, an interactive shell (we use IPython) with all of the compiling and debugging utilities you need is easily a 5x efficiency boost, e.g. I can run `./devshell.py <NAME_OF_TARGET>`, then `run('foo', 'bar')` and the script will compile, upload, and re-execute the `foo` and `bar` modules. Makes onboarding much easier too.

[0]: https://www.youtube.com/watch?v=Pax5jIz6m_Q

A lot can be done, even in languages that compile quite slowly, to get good performance in practice. See, for instance, what one can do with bazel and build servers. A cold compile is still not going to be good, but you'll never do a cold compile, and it will be very rare to recompile something that will require changing the entire tree.

At an old job, we had files that were slow enough that we'd have them in a separate compilation unit (automatic derivation of typelcasses with multiple serialization schemes) , so if you didn't change them, you'd just be picking up the binary. And if you were changing them, you weren't changing anything else, so ultimately a very slow compilation step was never a thing.

But yes, it's a matter of investment that few companies are willing to make

C# compiler has like tens of milions lines of code and it compiles in a minute or two

So you either worked on the biggest codebases in the world

Or youre doing CPP :)

What is your measure of interesting? Of "medium" sized? Go probably compiles 15K lines/sec.

Elm has always been very fast in my experience, but I have only worked on small-medium sized projects

the real problem is build time with the windows filesystem (in my case). switching to wsl2 you get under 20 sec. pretty easily, and most projects > 20 seconds are fixable (that is, if someone fixes it). Deploy time, on the other hand...