Hello, these are profiles (from gradle-profiler) o...

# multiplatform

[Krystian Kaniowski]

Hello, these are profiles (from gradle-profiler) of my debug and release builds for iOS. The linking task is very long for debug, but extreme long for release build type. Both runs on m5 pro with org.gradle.jvmargs=-Xmx16g. Of course any change in source code trigger whole linking task again.
• linkDebugFrameworkIosSimulatorArm64 ~ debug: total: 3:26, link: 1:48 (left)
• linkReleaseFrameworkIosSimulatorArm64 ~ release: total: 18:00, link: 16:23 (right)
I wonder if this is expected for >200 KMP gradle modules, >400k KMP LOC? Is it possible to reduce release time somehow?

[Chrimaeon]

• Please refrain from cross-posting the same message on multiple channels. It is considered spamming.

kotlinlang.org/docs/slack-code-of-conduct.html#…

[Krystian Kaniowski]

sorry for smaping, it was hard do guess where is it will be possible to find the answer

[Krystian Kaniowski]

sounds more like multipaltform (ios) project, but maybe it is something to change in gradle

[Krystian Kaniowski]

this is why I decided to post it in both channels

[François]

https://kotlinlang.org/docs/native-improving-compilation-time.html

[Chrimaeon]

well, then just “link” the two, so others that are looking for the same issue will find the answer regardless where the discussion is going on.

Also did you search in the slack channels here - I think it was discussed a couple of times.

[François]

Also reducing the size of your umbrella is really helpful

[François]

@Chrimaeon yes, that’s already asked

[Krystian Kaniowski]

what do you mean by reducing size of umbrella? currently I have only metro app graph interface + 5 files in src, the rest are depedencies of all modules included some via implementation and some via api to meet all DI dependencies

[Krystian Kaniowski]

do you suggest to hide metro entrypoint belove umbrella, and expose to ios as less as possible

[François]

It's the generated .h you can find beside the kotlin framework, that’s all the exported kotlin code to iOS.

[François]

Bigger the file is mean longer build time and bigger binary size.

[François]

That's something JB should add in the official documentation, the impact can be huge.

[François]

+ follow the existing recommendations. That’s all I can share.

[dylan]

Being strict with adding the internal keyword where possible and not exposing everything in every module will also help with faster builds and more build cache reuse in normal builds also.

[François]

That's a basic 👍