-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce stuttering in post listings #483
Conversation
We desperately need an android / jetpack-compose performance expert on this. I'm 99% sure we're missing something trivial in either the code or our release compilation, that would make these hacks unecessary. |
Yeah I don't know, I've seen tons of posts online about bad LazyColumn performance it could definitely be Jetpack Compose's fault. Or maybe the issue is that recomposition of a single |
Yep, its very possible that the I don't see why it would be getting recomposed tho. When I did try to optimize things months ago, adding keys and such to lazylist, it didn't really improve anything, and I wasn't smart enough to be able to use the info from that android studio recomposition count view. |
I think it does recompose since it needs to know what has changed, which is only possible by calling the composable function again. It's only after calling this method that the |
What's that tool you're using? If I could figure out how to read that I could help a bit. Looks like the CircularIcon might be the issue? |
@dessalines I may have found the tool he was using. and cntrl + f for |
I followed this guide.
It does look like that but the graph doesn't make much sense. For example, it's implying that |
Stale PR. I can re-open if necessary. |
I've managed to alleviate the constant stuttering every time a new post listing enters the screen by grouping a few posts into groups. This way the LazyColumn only has to create and destroy components much less often, reducing the feeling of stuttering.
This of course means that, whenever a new group must be created or removed, the stutter is more noticeable. However, this stutter doesn't seem to scale linearly with the amount of items per chunk and it's only slightly more noticeable than the stutter caused by every single item, so I think the trade is worth it.
If we decide that this is a good way to do it, it should be possible to make the same improvements to the comment nodes.
The current chunk size is set to 10 as a completely arbitrary number, we could play around with it to see what works best or even set it to the amount of items returned in a single post fetch call.
When/if #411 is implemented we could probably get away with grouping an entire page into a single chunk, making the experience completely stutter free.
I have also disabled the home top bar coming in and out as you scroll because it was a huge cause of lag, however this was only for testing purposes and I imagine we might wanna re-enable it later.
Fixes #445 somewhat.