In a current project, I have fewer than 20K lines and it's 50ish seconds for a clean re-compile on a very decent laptop (less than a year old, 32Gb RAM, quadcore i7, fast PCIe/NVMe SSD, etc.).
Particularly as I'm a test driven type of developer - cycling between running unit tests and adding small fixes is painful. Even when you can trust the incremental compilation, 10 or 20 seconds between making small one-line fixes and the test re-starting means the temptation to check hackernews or whatever kicks in and any chance of achieving "flow" evaporates.
I'm almost considering the suggestion (for Scala) in the article - and moving back to Java.
The Kotlin compiler is slow, but if you break up your code into smallish modules and build with Gradle, it will only re-compile the modules that require re-compilation after changes which should make compilation times much shorter than 50 seconds.
At work, we have around 100 modules I think (some Kotlin, most Java though) and changing the API of the lowest level ones (used by everything else) usually causes re-compilation to take a minute, but as most changes are in the higher level modules (which are not depended on by anything else) and re-compiling those takes a second or two, it's not been a big problem for us.
I envy your 50ish seconds. Especially since it sounds like you could cut that down quite a bit with a beefier build rig.
I do kernel development, and for me the turn around for a one-line change is 4-minutes to 2+ hours. About 60 seconds for the build (32-core Threadripper, solid state storage), about 30 seconds to tar up the kernel and scp it to a test box, and about 2 1/2 more minutes to install the kernel and reboot (most of which is in the super slow uEFI bios). That's the 4 minutes for a trivial change.
Somewhere in the middle is ~40-ish minutes for our central CI service to run all the unit tests when a branch is pushed to.
But the 2+ hours is what I encounter most often. That is for testing non-trivial changes on production traffic. It takes over an hour to gently ramp a box down from full load to no traffic (so I can install a kernel an reboot), and another 1+ hours to ramp it up with customer traffic. Since we're testing in production, it means I often want to watch the machine closely, so that I can gracefully ramp it down if things start going pear shaped.
I agree that leaves way too much time for distraction. I try to multi-task and have multiple projects in flight at the same time in order to make more effective use of the waiting time.
I see your 2+ hours and I raise you 1/2 of a server year of test regressions for every commit to the main trunk, beginning with a 2 hour wallclock-time build of all the models needed for running CPU simulations. Total wall-clock time for edits to hit the trunk is 2.5 days.
In response to your question, I just bumped it to 1.4.32 and haven't observed a significant improvement.
Back in the old days, compiler metrics were often quoted using units of 100s of thousands or even millions of lines per second.
I know the Kotlin compiler has to do a lot of work but I would have imagined hardware advances should balance this out somewhat. Instead I'm looking at compile speeds quoted in hundreds of lines per second.
In a current project, I have fewer than 20K lines and it's 50ish seconds for a clean re-compile on a very decent laptop (less than a year old, 32Gb RAM, quadcore i7, fast PCIe/NVMe SSD, etc.).
Particularly as I'm a test driven type of developer - cycling between running unit tests and adding small fixes is painful. Even when you can trust the incremental compilation, 10 or 20 seconds between making small one-line fixes and the test re-starting means the temptation to check hackernews or whatever kicks in and any chance of achieving "flow" evaporates.
I'm almost considering the suggestion (for Scala) in the article - and moving back to Java.