Our biggest pain with Multiplatform right now is t...

# multiplatform

[Paul Woitaschek]

Our biggest pain with Multiplatform right now is that it links the targets in sequence which leads to extremely long release build times. @tapchicoma is this on the roadmap any time soon?
https://youtrack.jetbrains.com/issue/KT-49385

[tapchicoma]

Last time I've tried to migrate Native link to use workers - it haven't brought any build performance gains. Link task itself does heavy cpu and memory computation and running them in parallel does not help as they start to compete for machine resources.

Possible solution is introduce kotlin.native.linkParallelism property which will allow to fine-tune how many link tasks could run in parallel (default would be Gradle workers count)

[Paul Woitaschek]

I’ve just tried it on an incremental build and I think it would speed it up.

[Paul Woitaschek]

image.png

[Paul Woitaschek]

Even if the link tasks wouldn’t benefit from it, the ksp and compile tasks would

[mikehearn]

But what does the CPU / memory load look like during the serial link operation.

[mikehearn]

BTW I think Apple have improved the speed of their linker in the new toolchains by parallelizing it better. It was announced at WWDC. If the linker itself is parallelized, it's not clear that running several at once would make anything faster.

[Paul Woitaschek]

It’s always ksp - compile - link - ksp - compile - link - …
And that compile and ksp should benefit from it, even if the linking didn’t

[mikehearn]

Is it possible to parallelize ksp and compilation? Or do you mean overlapping the targets?

[tylerwilson]

This would be nice. My full XCFramework build takes about 15min, which seems crazy on a decent M1 Pro machine...

[Paul Woitaschek]

We are at 50 minutes with a m2

[Paul Woitaschek]

(Mac Mini)

[mikehearn]

And there's lots of spare CPU capacity on the M2 during the build?

[mikehearn]

I wonder if there's a quick fix here using mold or the new Xcode.

[tapchicoma]

maybe I need to revisit initial approach and check current build times when repo has many native targets

[Paul Woitaschek]

we are at 80k lines of kotlin. If you like you can send me Kotlin snapshots where you'd like to get real world build times

[ephemient]

with --configuration-cache Gradle is able to run multiple tasks from the same project in parallel: https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:intro:performance_improvements

[ephemient]

although it seems multiplatforrm has issues with configuration caching currently?

[Paul Woitaschek]

Yep, at least 1.8.21 isn’t compatible:

- Task :library:linkReleaseFrameworkIosArm64 of type `org.jetbrains.kotlin.gradle.tasks.KotlinNativeLink`: invocation of ‘Task.project’ at execution time is unsupported.

[Paul Woitaschek]

`- Task :library:linkReleaseFrameworkWatchosArm64 of type `org.jetbrains.kotlin.gradle.tasks.KotlinNativeLink`: value '{org.jetbrains.kotlin.native.target=watchos_arm64}' is not assignable to 'org.jetbrains.kotlin.gradle.plugin.mpp.HierarchyAttributeContainer'`

[tapchicoma]

Try with 1.9.0-beta - should support CC

[Paul Woitaschek]

Holy moly that’s a gamechanger!
That was on my m1 mbp with --rerun-tasks

[Paul Woitaschek]

@tapchicoma
Seriously, the impact is huge. Here is the same build but without config cache. The name configuration cache is really misleading as it unlocks a huge potential that is not related to caching the configuration phase.

[ephemient]

it is related - in order to implement configuration cache, tasks are prevented from touching the (shared, mutable) project, which in turn makes it safe for Gradle to parallelize at that level