Is there anything particular that drives up the ko...
# announcements
t
Is there anything particular that drives up the kotlin compiler memory usage that one should look out for? I am generating code using Kotlinpoet and I am struggling with very high memory usage during compilation (I had the similar problem in an earlier project with 1.3.x, but back then it was enough to just give it more memory -- now that doesn't solve it due to a higher number of classes). The code generated is not deep (so no big nested if-s or anything, but 3 methods, a number of static variabled defined in the companion object. I guess the most risky might be a data class that has about 20000 different uses. It is currently just over 600 such classes, and they are in the same package -- would splitting up the packages help?
The main heap culprits (heap-dump-on-out-of-memory and then Eclipse MAT) is 500MB of org.jetbrains.kotlin.cli.jvm.compiler.NoScopeRecordCliBindingTrace (11067 of them), and the rest is for the most part held on the heap by 53,683 instances of org.jetbrains.kotlin.load.java.structure.impl.classFiles.BinaryJavaMethod, in total 3.7 GB (75% of the heap).
So it seems, from a naive point of view, that ClassifierResolutionContext is holding on to most of it.
Which again leads to a ton of SmartList, amongst other things
After regenerating the code in many variations, it seems the function with a lot of if()-tests (but not nested) is the killer for memory consumption. In the end, the only workaround that works is kotlinc with -Xuse-javac .
d
Hi. Could you please file an issue (http://kotl.in/issue)? And it would be great if you attach project with reproducer to it