https://kotlinlang.org logo
Join Slack
Powered by
1. Is there any roadmap for dealing with performan...
# compose
m
1. Is there any roadmap for dealing with performance issues? I have just tried to run my compose app on an older phone and it lags bad. Specifically scrolling through LazyColumn and Pager is very laggy. 2. Does it make sense to use RecyclerView / old ViewPager - insert them into a composition and fill them with composables? Is it gonna make it faster or slower? 3. Is there anything I can do to maybe trace the performance issues (more things like this) or any specific modifiers or composables which should rather be avoided? [Edit] my specific issue is more or less solved, some explanation in thread.
➕ 5
a
In reverse order, 3) ui.perfetto.dev is one of the tools we use frequently to investigate performance. 2) based on our benchmarks you'll see similar performance between the LazyColumn/RecyclerView or ViewPager/Accompanist Pager in all-views, all-compose, or mix and match configurations. 1) Can you post your code so that we can determine if what you're seeing is something we're tracking/have addressed/is specific to what your code is doing?
A few things we're aware of include: loading vectors with 
painterResource
has some pathological behavior around repeated loading and if used in a LazyColumn or similar it's easy to see it fall off a cliff
first-time/first day startup before ART's profile-guided optimization compiles the app code; we've got some more to share about this soon. If the performance settles after the first few interactions with your UI you might be seeing this contributing
m
Thanks for response @Adam Powell. I have lots and lots of stuff there, it's a book reader app, the main thing there is a Pager with book pages and then each page consists of a LazyColumn of different sections. I should probably try to reduce it to some smaller example and then get back to you, wdyt? I do have some vector icons there and some are repeated, will look into it. So you say that compose views should already be performant like the traditional ones with a few small exceptions? Because I read this today and it chilled me a bit: https://github.com/android/compose-samples/issues/21
If the performance settles after the first few interactions with your UI you might be seeing this contributing
Yes, it seems that it gets a bit better over time, but it's far from perfect still. I have an old app which shows basically the same data and is much more performant
a
😄 I wouldn't worry too much about an issue filed and closed in 2019. An immense amount of performance optimization has landed in compose over the past 6 months in particular
✔️ 2
The smaller the repro example, the better
m
alright, so the plan is - I try to profile it a bit first, and if I can't find the culprit, I make a small repro - I understand that a gist with a Composable should be enough, not a full app, right?
a
yep, anything that can fit in a
Copy code
markdown code snippet
on the issue tracker is even better, but gists or even sample apps can be helpful too.
The smaller the example the easier it is for us to investigate it 🙂
m
thanks, will get back to you here 🙂
👍 1
a
Another thing is make sure you measure the performance using release builds as debug builds are unoptimized and there can also be a lot of extra code (such as live literals support code) which will affect performance.
🙏 2
a
that too, yes. r8 makes a difference as well
s
I hope, there will be some thing like this in Compose as well to debug performance issues. https://twitter.com/luka_bernardi/status/1402045202714435585?s=20
➕ 1
a
we've got some really neat stuff on the debugging front in mind 🙂 nothing to share just yet though
🙏 3
❤️ 3
m
Okay, I think there are 3 components to this: 1. release+r8 vs debug is night and day, didn't expect this to play such role - compose adds a lot of this debug stuff? - the difference wasn't so apparent with the old views, I think. 2. I have a quite simple vector icon (down arrow) which is repeated a lot in these layouts. If I remove it, scrolling becomes a bit smoother. 3. I use Coil to load images from disk (they are attached to those books). Sometimes there are quite a few of them shown as thumbnails (think dozens) and their original size is significant. When I replaced them with some 300x200 lorempixel it made a huge difference. I expected Coil to downsize the files automatically based on the view size (it's constrained to be 100dp high), but I begin to suspect that it doesn't reduce them since they are loaded from disk, not network. Will try to force resize them to thumbnail size or try Glide instead. These 3 things make the app run at least as smooth as the old one. When it comes to those vectors, is there any issue I could follow? Anyway, as always 5 ⭐ support @Adam Powell :D
❤️ 3
👍 4
a
great to hear! Are you using the coil composables from accompanist? cc @cb if there's any potential issues in there
iirc the accompanist coil composables do inform the loading process of the target layout size of the image element but I'm not 100% sure what all it does with that info today
m
Copy code
Image(
                painter = rememberCoilPainter(
                    request = Uri.parse(photo.image.filePath),
                    fadeIn = true
                ),
                contentDescription = null,
                modifier = Modifier
                    .height(100.dp)
                    .padding(horizontal = 8.dp)
                    .clickable { onGalleryShown(GalleryState(tNote.photos, i)) },
            )
this is how my coil Image looks, it's powered by accompanist indeed
r
@Michal Klimczak the difference isn't as noticeable with Views because they are precompiled ("AOTed") as part of the system image
✔️ 1
c
Yeah, I'm also noticing some funkyness with accompanist coil. Things that use coil accompnist to load images just aren't as snappy as they were in the view world and sometimes (rarely but it does happen) my composables just won't display an image. I have a lot of composable wrapped in AnimatedVisibility and I figure maybe its related to that. I plan on getting some heads down time next week to make a small repro as I thought it'd iron itself out by now.
👍 1
m
If you remember, CC me on that repro pls @Colton Idle :)
c
The issue with that example is that you’re not constraining the height. Just providing the width isn’t enough to know what size to load. Set a height, minimum height or aspect ratio on the composable, and it should work better.
Some of this is caused by the fact that Painters don’t get access to the layout constraints, only the resolved sized. If we don’t get a size we have a fallback to load the full size image. I have a PR to constrain that to the window size, but it hasn’t landed yet. https://issuetracker.google.com/186012457
m
Thank you @cb. Will do. [Edit] I wrote more but then read the issue and realised where the problem lies :).
first-time/first day startup before ART's profile-guided optimization compiles the app code; we've got some more to share about this soon. If the performance settles after the first few interactions with your UI you might be seeing this contributing
@Adam Powell have you shared anything about this or has anything changed in the last 20 days?
a
Has anything changed about it: yes Have we shared anything about the results yet: no, not yet 🙂
👌 1
➕ 1
m
Waiting patiently :D
➕ 3
@Adam Powell it's been a month so just a kind reminder - now there's compose stable released maybe you have something more to share about it? we're still seeing the first interactions with the app being noticeably more laggy and then after a few scrolls it's all nice and smooth.
r
m
Awesome, thanks!
4 Views
Open in Slack
PreviousNext
Powered by