Tyler Rockwood06/21/2022, 7:18 PM
flag to the compiler run.
We've tried to turn on
info: PERF: <redacted_module_name>, 1 files (23 lines) info: PERF: INIT: Compiler initialized in 1758 ms info: PERF: ANALYZE 4307 ms 5.340 loc/s info: PERF: IR TRANSLATION 289 ms 79.585 loc/s info: PERF: IR LOWERING 494 ms 46.559 loc/s info: PERF: IR GENERATION 348 ms 66.092 loc/s info: PERF: GENERATE 842 ms 27.316 loc/s info: PERF: GC time for G1 Young Generation is 47 ms, 2 collections info: PERF: GC time for G1 Old Generation is 0 ms, 0 collections info: PERF: JIT time is 22892 ms info: PERF: Find Java class performed 11 times, total time 234 ms info: PERF: Type info performed 39 times, total time 2214 ms info: PERF: Call resolve performed 38 times, total time 2116 ms info: PERF: Binary class from Kotlin file performed 210 times, total time 226 ms
but that fails due to https://youtrack.jetbrains.com/issue/KT-52824. In general we don't have any compiler plugin ourselves, although Bazel uses
for better compilation avoidance. Are we just hopeless until K2? I've ran across issues like https://youtrack.jetbrains.com/issue/KT-38101 that performance issues (at least in the analyze phase) are being fixed in K2 (which we can't try in alpha yet because of the missing support for plugins). In the release notes for Kotlin 1.7 there was a section that posted performance numbers and there are current packages getting 1-2K loc/s with the current compiler. Even our largest modules (assuming there is some constant overhead that is making the above example so bad) maxes out at about 100 loc/s (5.8k lines in 5 files taking around 57 seconds). Are the Bazel kotlin rules invoking the compiler incorrectly to lead to such bad performance? I'm happy to talk though the threading model and how the Bazel rules invoke the compiler with someone if that turns out to be the issue.
dmitriy.novozhilov06/21/2022, 7:56 PM
Tyler Rockwood06/21/2022, 7:58 PM
dmitriy.novozhilov06/21/2022, 8:01 PM
Tyler Rockwood06/21/2022, 8:02 PM