Hi, we’re running into an issue where Kotlin Nativ...

# compiler

[Waldemar Kornewald]

Hi, we’re running into an issue where Kotlin Native (on iOS at least) produces pretty large binaries of >70MB and as a consequence overall compile times are hardly bearable anymore (1h with the 1.9 LLVM pipeline preview, >4h with normal 1.8 pipeline). Note that we’re building SDKs and thus export many modules. The corresponding JVM and JS output is just a few MB. Of course those other targets can rely on a whole VM, but I would’ve expected the overhead to be pretty constant, e.g. 5MB. In our case it feels like 90% of that huge binary is pure overhead. How difficult would it be to fix the compiler to produce more compact code getting us much closer to the JVM and JS output size?

[dmitriy.novozhilov]

cc @svyatoslav.scherbina

[Waldemar Kornewald]

FYI, that particular SDK is 210K LOC in size, measured with tokei

[svyatoslav.scherbina]

Hi.

1h with the 1.9 LLVM pipeline preview

I think we discussed your case in YouTrack, and the compilation time with Kotlin 1.9 should be faster than that. Please create a new YouTrack issue.

How difficult would it be to fix the compiler to produce more compact code getting us much closer to the JVM and JS output size?

Literally impossible to say without more details about your project and configuration. Let’s discuss that in the new YouTrack issue.
Just in case: have you tried tips from https://kotlinlang.org/docs/native-improving-compilation-time.html? Especially about transitiveExport.

[Waldemar Kornewald]

Yes I reported our case back then when 1.8 had a regression and would result in >4h compilation. The new pipeline is much faster, but still almost 1h which is similar to the 1.7 compile times.

We don’t use transitiveExport, but in the end we do export almost all of our dependencies because we really need everything.

I can create a new issue but I also thought chatting and maybe even screen sharing here directly would make it easier to debug.

[svyatoslav.scherbina]

we do export almost all of our dependencies because we really need everything.

Why? Could you please provide an example of an exported dependency, and the reason behind that?

[Waldemar Kornewald]

kotlinx-datetime is exported together with our own helper module which provides ZonedDateTime and an arbitrary-precision datetime (Year, YearMonth, LocalDate, ZonedDateTime) because we have to deal with such data a lot. Sometimes we export a whole module like e.g. our tiny XML parsing API (just a small wrapper around various platform specific APIs) but we mostly do that because the exceptions can bubble up in our code and we didn’t want to re-map all of them to a different exception type defined in the higher-level SDK. For such a small lib it wouldn’t be worth it. Then there’s a PDF printing API, crypto APIs and so on, but mostly rather small compared to the big primary module. In any case, iOS needs to interact with those other modules’ types, though maybe not absolutely all of them. And it needs to interact with almost all of the primary module APIs.

[Waldemar Kornewald]

BTW, I’ve created a private ticket https://youtrack.jetbrains.com/issue/KT-59614

and also another one for a different issue which is a show-stopper https://youtrack.jetbrains.com/issue/KT-59612 (though we might have an ugly workaround as an intermediate solution)