https://kotlinlang.org logo
Join Slack
Powered by
We are trying to POC compose for iOS and everythin...
# compose-ios
d
We are trying to POC compose for iOS and everything looked good until we got to a screen with a LazyColumn.. There are substantial frame drops on even the most simple composables. I found this ticket https://youtrack.jetbrains.com/issue/CMP-4438, which seems to be whats tracking. Has anyone else had similar experiences with lazy columns on iOS?
➕ 1
k
this is too common description for the issue. we have an observation the 99% issues here are incorrect written composable code. so, to help you we need a reproducer. could you attach a small project with a description how to reproduce the problem?
d
Of course! I can put something together.
u
Do you test on release builds?
k
Does it make a difference on iOS?
k
YES! more than you think 😆
c
Really? What about release builds makes a difference? Somewhat related reading if anyone wants to take a look: https://kotlinlang.slack.com/archives/C0346LWVBJ4/p1704395951940269
k
@Elijah Semyonov could you elaborate a bit?
e
Can you specify a version you are using? Because there was a logical problem on how widgets utilising subcompositions (e.g. Lazy_Anything_) were doing things that lead to perceived bad performance and it was fixed. Speaking of K/N, it’s a whole different beast rather than JVM targets. Performance of debug and release builds differ drastically, because the whole power of LLVM optimisations passes in unleashed on release which is a serious trade-off when it comes to compilation times, which is more important during development iterations.
We don’t do any profiling on debug builds and I’m not aware of any plans on improving performance specifically targeted on debug builds.
The general idea is that a correctly written app with good performance characteristics on Android should have the same performance on release build iOS, which is ultimately the product you deliver to your users.
❤️ 3
So it you have performance issues on iOS in release but Android works fine, then it’s indeed something we want to investigate and improve, so please, post a relevant repro, video, your commentary about what feels wrong and versions you use.
❤️ 3
@Andrei Salavei has recently started an investigation of some performance issues, but is temporarily unavailable, may be your case could be relevant
👀 1
❤️ 2
The general difference is that K/JVM is JIT, and and K/N is AOT which puts a lot of interesting effects into the play when it comes to performance, but there is a ton of information about it in the internet, so feel free to delve into it
K 2
d
Thanks all, for your responses. I'll give it a go on release. If we still see issues I'll open up a you track with the relevant information.
🙌 2
So building a release version made everything smooth as 🧈 . The problem is that it takes over an hour to build locally and over 2 on CI on M1 hardware... which is over our timeout limit 😞
👍 1
We have a large project. 170 modules with all the non UI code on KM
e
Please post an issue on YouTrack about compilation times, we use your feedback to decide what to focus our efforts on. A constructive real world use case is always something we can use internally to push certain things.
d
Alright, I can open a ticket comparing build times with and without compose included.
👍 1
e
Provide as much data as possible, it really helps
d
anything specific that you may be looking for so i can make sure to include
e
Eh… It’s not exactly my area of expertise. @Konstantin Tskhovrebov do you know by any chance what kind of info could be useful for our build/compilation folk?
k
It is enough to file the issue in the kotlin tracker and ask which information they need
👍 2
d
Thanks guys. Ill post the ticket here once i gather the info.. might take a couple days with build times as 2 hours laugh cry face palm
4 Views
Open in Slack
PreviousNext
Powered by