Just started using Hot Reload (alpha10). My reloa...

# multiplatform

[Rok Oblak]

Just started using Hot Reload (alpha10).

My reloads take about 10 seconds on a M3 Max (for example changing a height in a modifier). Is this expected?

[Rok Oblak]

I see that the composeApp:compileKotlinDesktop (8789 ms) is run every time

[Kashismails]

iit really depends on how your build is structured as you checked the logs it builds everytime, you can create a seperate module for components this ways builds are faster and thus hotreload

[zsmb]

You could try the kotlinconf-app project, on my M2 Max it takes a couple seconds at most to perform a reload in there, even cross-module. Either your project is significantly larger, or something might be suboptimal in your build configuration / caching.

@Sebastian Sellmair [JB] might be able to comment more.

[Sebastian Sellmair [JB]]

Compose Hot Reload is currently the technology which reloads your code in a live application. How the code is compiled is unchanged, therefore builds with incremental compile times of, lets say 10 seconds, will also have to wait 10 seconds for the classes to arrive before Hot Reload is able to swap them on a live application.
We'll stabilize this core technology first, then we can look into our build infrastructure and figure out why sometimes incremental builds take so long for people. I am sure that something is not right and we can squeeze a lot here 😎

So far, the best things you, as a build author, can do is:
• enable Gradle configuration cache
• enable caching
• structure the project to optimize for quick IC builds
• Follow Gradle best practices to avoid unnecessary work being done on IC builds

[Asapha]

If it's like me, you're probably experiencing non-incremental builds when making changes in commonMain
To verify this
• add kotlin.build.report.output=file to gradle.properties
• compile once, make your padding change, compile again
• check build/reports/kotlin-build at the root
• You should see Non-incremental compilation will be performed: UNSAFE_INCREMENTAL_CHANGE_KT_62686 in the txt file
(Referenced issue)

[Rok Oblak]

Thanks! Yes indeed it is the same issue,
UNSAFE_INCREMENTAL_CHANGE_KT_62686

[Rok Oblak]

Interesting that I do not find anything related other than this ticket, and this ticket was supposed to have been fixed in 2.0.0 beta3? I am on 2.1.10

[Sebastian Sellmair [JB]]

cc @tapchicoma (Sorry Yahor for pinging you, but I think you're the best one to dispatch the IC topic?)

[tapchicoma]

That is true for IC in multiplatform - it never compiles incrementally the same module. Though compilation avoidance for JVM should work. The problem is fundamental in the Kotlin compiler and compiler team is working on the proper solution.

[Sebastian Sellmair [JB]]

cc @Azat Abdullin: (So you're also in the loop)
To summarize: Compose Hot Reload is stabilizing the tech to reload the classes, the Compiler team is working on drastically improving the incremental builds.

[Wojtek]

Is there any issue regarding the incremental build? Yahor said: "The problem is fundamental in the Kotlin compiler and compiler team is working on the proper solution." but I couldn't find any issue to track it (created https://youtrack.jetbrains.com/issue/KT-82893/Non-incremental-compilation-will-be-performed-UNSAFEINCREMENTALCHANGEKT62686) as I'm facing exactly the same issue and while those 5-7s may not sound like a lot, when doing small changes and trying to see the result having to wait for the whole module to rebuild quickly adds up :)

[Sebastian Sellmair [JB]]

Yes, the team is working on improving IC build for KMP projects.
There are some differences in the compiler invocation, compared to 'just jvm', which make IC a little bit harder.
I know there are tickets in YT to track this effort: https://youtrack.jetbrains.com/issue/KT-63353/K2-KMP-Incremental-compilation
I hope that we have something in preview for you folks soon, but I am not in the context of this effort atm

[Rok Oblak]

Thank you! I am not sure what in my project - if anything - is different such that I have an issue with incremental compilation, but if it is not working properly, then waiting 5-10 seconds on any tiny change is almost a deal-breaker not fully enjoyable for preview/hot reload.

[Sebastian Sellmair [JB]]

is almost a deal-breaker for preview/hot reload.

Would it be fair if I'd reformulate it to 'is almost making preview/hot reload *unejoyable*'. Regular restarts will similarly suffer from the 5 to 10 second delay, right?
However: Are you using a KMP project and is one of the modules rather large?

[Sebastian Sellmair [JB]]

Do you have configuration cache enabled (and is it OK for you?)

[Rok Oblak]

yeah, completely agree. Hot reload is an amazing feature, just a pity that due to an unrelated issue I cannot enjoy it fully, as intended.

[Sebastian Sellmair [JB]]

Fair! Fully understood, I feel with you!

[Sebastian Sellmair [JB]]

Is your project accessible publicly, or would you be in for meeting with me for a 30 min 'let's see whats going on' session? (Signing an NDA is totally OK for me as well, if this would be required)

[Rok Oblak]

That would be great! unfortuntately I cannot do today/tomorrow, but afterwards anytime would work. Only if it is not an invonvenience for you.

[Sebastian Sellmair [JB]]

No, I would be very interested to get a feeling/understanding of your projects needs.
Its really important for me to 'stay in touch' with the real world (outside of JetBrains), i'd be a pleasure.
I'll DM you for setting up a meeting 👍

[Wojtek]

> There are some differences in the compiler invocation, compared to 'just jvm', which make IC a little bit harder.
> I know there are tickets in YT to track this effort:
Thank you for the link - I'll follow it.

I assume it's a "know issue" and you have certain ideas how to fix it but it requires some time and effort? 🙂

[Sebastian Sellmair [JB]]

To share the result of the tinkering:
@Rok Oblak and me were able to reduce his incremental compilation speed from 10s down to ~1s by enabling Gradle configuration cache and enabling unsafe incremental compilation for KMP (which shows that IC will have a huge impact)

[Rok Oblak]

Yes, this was a huge change, many thanks to @Sebastian Sellmair [JB] for hopping on and helping!

[Wojtek]

Gradle configuration cache and enabling unsafe incremental compilation for KMP (which shows that IC will have a huge impact)

Which property is this "unsafe incremental compilation"?

Looking at https://kotlinlang.org/docs/gradle-compilation-and-caches.html#incremental-compilation I only see mention of regular incremental compilation and how to disable it explicitly. I searched the internet but nothing relevant stood out.

I did find https://youtrack.jetbrains.com/issue/KT-62686/K2-Common-module-sees-platform-declarations-in-case-of-MPP-project-incremental-compilation#focu[…].0-0 which mentions kotlin.internal.incremental.enableUnsafeOptimizationsForMultiplatform=true which seems to reduce the time from ~7s to ~3s which is quite nice but I do wonder are there any other options / properties 🙂

[Sebastian Sellmair [JB]]

We will ship a managed version in Compose Hot Reload 1.1.0-alpha03 (or beta01), which automatically handles such properties for you. We will refrain from advertising the properties publicly, as they might be OK for recompiling certain code during hot reload, but not OK for any production code

[Sebastian Sellmair [JB]]

@Wojtek: The remaining 3s might be Gradle configuring? I assume you have gradle configuration cache enabled?

[Sebastian Sellmair [JB]]

Compose Hot Reload 1.1 will also enable further build optimizations out of the box, so we will be quite eager for feedback!

[Wojtek]

@Sebastian Sellmair [JB] hmm… whole task took 2s997ms, of which module build was 1s870ms

[Wojtek]

Though I'm tallking about Compose preview and not hot-realod (not sure if this matter in this context)

[Wojtek]

Hmm… I updated compose plugin from 1.8.x to 1.9.3 and now it takes 2s219ms / 1s371ms so that was probalbly it 🙂