Status Update
Comments
ch...@google.com <ch...@google.com>
al...@google.com <al...@google.com> #2
Triage notes: Still P3, still a real issue. Compat issue.
bu...@google.com <bu...@google.com> #4
bu...@google.com <bu...@google.com>
an...@google.com <an...@google.com> #5
This issue led us to explore redesigning the SlotTable. That ended up being infeasible, because while we gained modest performance improvements to small random writes and substantial improvements to reordering operations, we regressed too much in creation performance. Because creation is much more common of an operation and is critically performance sensitive, the net result of this attempt was a performance regression.
I'm going to move this issue back to our backlog for now. It's still a real concern that we'd like to improve on, but it's not something we're going to pursue for now. Whatever approach we might take in the future will most likely take a different shape than the attempted SlotTable rewrite.
al...@google.com <al...@google.com> #6
Triage notes: Working on some other ideas right now, updating status to track.
pa...@gmail.com <pa...@gmail.com> #7
Status update?
ch...@google.com <ch...@google.com> #8
No updates explicitly though this is still in active development.
We ran into some performance issues with the vesrion we were working and we had to redesign how our new slot table is implmeneted.
Description
Jetpack Compose component used: custom
Android Studio Build: N/A
Kotlin version: 1.7.20
There's a performance issue in the slot table, causing the re-composition to take tens of seconds with 10000 elements.
If the code is adjusted into a nested loop, the performance improves dramatically (from ~40 seconds to <1 second).
Sample code:
Slack discussion: