High CPU load in IDE when making any code change


Hi, I have a problem in my project where any change to a Kotlin file causes high CPU load for 30 seconds or so (25% load on my four core machine so looks like idea.exe is maxing out one core).

This is only a problem on my laptop - on my home machine things are working fine - for the same project. It’s only a small project with a handful of classes.

I tried deleting the project and re-creating from github but it didn’t help, so perhaps it’s something in my idea setup.

Make is also very slow - 45 seconds (Core i7 / 8Gb). I have another more complex project that compiles in under 10 seconds on the same machine.

If someone can help diagnose the issue I’ll be happy to create a ticket once I can put some more concrete info against it!

Thanks, Alfie.


I will re-check performance on my home machine, but the slow down seems to be related to heavy use of a groovy style builder.

Below is the source for the offending file. If I comment most of the nested function calls (the main states.forEach on line 80), I can get the compilation back down close to 10 seconds…


Is this a known issue and if so, is there any suggested workaround?

Thanks a lot, Alfie.

Hello, Alfie!

Yes, it looks like a known problem. It will be fixed in a while (we are currently working on it).

The  compile time of your code on my machine is not bigger than compile time  of 'introduction to kotlin  examples' (https://github.com/kotlin-projects/introduction-to-kotlin).  So you can try it on your laptop if you want, and if it's comparably  slow, than we know the source of a problem :) .

As a workaround suggestion you can simply wait a bit ;) or try to avoid deeply nested function literals.


Hi, thanks for the quick reply! Is there a YouTrack issue I can follow for this issue?



Hi, just for info, the kotlin examples project rebuilds in around 10 seconds on my laptop - compared with just under a minute for my project with nested function literals.



Hm. Ok, then we'll anyway wait the fix for the known performance  problem and then return to your code to check if it compiles faster. I've created an issue about your request (http://youtrack.jetbrains.com/issue/KT-3809) and I'll comment to it when it's finishes. =)