[Frontend] Infinite scroll causes high background CPU load #503

Open
opened 2024-01-26 16:22:20 +01:00 by mia-0 · 6 comments

When infinite scroll (“Automatically load more”) is enabled, it will periodically call a function which triggers expensive style/layout recomputation. This very significantly affects interactivity and battery runtime on low-end devices.

Disabling that feature improves responsiveness very noticeably, and I have also observed that my phone (with browsers based on Firefox) no longer suffers frequent GC stalls or out-of-memory conditions. (I’m not sure of the mechanism here but I tend to suspect memory fragmentation.)

When infinite scroll (“Automatically load more”) is enabled, it will periodically call a function which triggers expensive style/layout recomputation. This very significantly affects interactivity and battery runtime on low-end devices. Disabling that feature improves responsiveness very noticeably, and I have also observed that my phone (with browsers based on Firefox) no longer suffers frequent GC stalls or out-of-memory conditions. (I’m not sure of the mechanism here but I tend to suspect memory fragmentation.)
Owner

the core issue here is likely the lack of virtual scroller, which causes the utilized memory to be proportional to all loaded posts on the timeline, since they’re never un-loaded. it’s one of the main things that we’ll fix in the frontend rewrite, I tried to patch it into the current one before but found no success. As for the performance - automatically load more does what it says on the label, i’m relatively sure you’ll find the same cpu spikes when you press the load more button manually, it’s just less noticeable because it happens as a result of user action instead of automatically.

the core issue here is likely the lack of virtual scroller, which causes the utilized memory to be proportional to all loaded posts on the timeline, since they’re never un-loaded. it’s one of the main things that we’ll fix in the frontend rewrite, I tried to patch it into the current one before but found no success. As for the performance - automatically load more does what it says on the label, i’m relatively sure you’ll find the same cpu spikes when you press the load more button manually, it’s just less noticeable because it happens as a result of user action instead of automatically.
Author

I see. The behavior I’ve noticed happens very frequently though, about every 100 ms. Recomputations/page renders are triggered every time, whether or not new posts have been loaded or content has changed in other ways.

I see. The behavior I’ve noticed happens very frequently though, about every 100 ms. Recomputations/page renders are triggered every time, whether or not new posts have been loaded or content has changed in other ways.
Owner

Huh, this may actually be a different issue then

Huh, this may actually be a different issue then
Owner

I have a suspicion it could be

function setTimer() {
if (interval.value || !defaultStore.state.enableInfiniteScroll) return;
interval.value = setInterval(() => {
const viewport = document.documentElement.clientHeight;
const left = document.documentElement.scrollHeight - document.documentElement.scrollTop;
if (left > Math.max(viewport * 3, viewport + 4000) || document.documentElement.scrollTop - lastFetchScrollTop.value < viewport) return;
pagingComponent.value.prefetchMore();
lastFetchScrollTop.value = document.documentElement.scrollTop;
}, 100);
}

, but I don't understand why getting clientHeight/scrollHeight/scrollTop could be this of an expensive operation

I have a suspicion it could be https://iceshrimp.dev/iceshrimp/iceshrimp/src/commit/706ff84d8dfcdb6a98bb65308d69c926d37424a1/packages/client/src/components/MkNotes.vue#L68-L77, but I don't understand why getting clientHeight/scrollHeight/scrollTop could be this of an expensive operation
Author

I suppose it forces a recompute for off-screen areas that would otherwise be in suspended state. CSS animations for example would probably necessitate this.

I suppose it forces a recompute for off-screen areas that would otherwise be in suspended state. CSS animations for example would probably necessitate this.
Author

In that case, it would probably help to reduce the complexity of elements in this calculation. Does it need the entire document or will a smaller element suffice?

In that case, it would probably help to reduce the complexity of elements in this calculation. Does it need the entire document or will a smaller element suffice?
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: iceshrimp/iceshrimp#503
No description provided.