Hacker News Reader

Comment by derriz | Hacker News Reader

Kotlin compile times are killing me.

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.

View on HN

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.

Android development is the worst. Not single thing about it is good. All slow, all the time.

And Gradle, what kind of sick joke is that?

BTW: Is possible to replace Gradle for android development with something good???

And I was complaining about a 4s rebuild time for a similar (number of lines) .NET 5 solution

Compile time is the only reason i moved to reactnative. It has some issues, but its well worth to have the fast build cycle.

does it not have incremental compiles?

at least Scala incremental compiles are fast. Haskell too!

it's a nightmare isn't it. Are you using the 1.4 compiler?

Yes it's a nightmare. I'm using 1.4.30.

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.

Reply on news.ycombinator.com