Performance Issues on Scroll with Large Data: 'b-released' Elements Not Removed from the DOM

[nagasain]

Hello,

We have observed significant increases in tab memory and JavaScript memory when handling large datasets. Below are the findings contributing to this issue:

1) 'b-released' DOM Elements Persist: Despite clearing the eventStore, 'b-released' DOM elements are not removed, resulting in an accumulation of DOM nodes and an increase in memory usage.

2) Detached Elements in Memory: Even after manually removing the 'b-released' nodes, additional detached elements remain in memory, further contributing to the increased memory consumption.

The rising memory usage causes noticeable lag during scrolling, even after only a few scroll attempts. Since smooth scrolling is a fundamental user interaction, this lag significantly impacts the user experience.

We have attached the event template and a video recording for reference.

Bryntum Scheduler - Big data set vertical demo.mp4

(17.61 MiB) Downloaded 12 times

SampleEventTemplate.txt

(976 Bytes) Downloaded 11 times

[johan.isaksson]

Hi,

When event bars are scrolled out of view they are "released" (get .b-released applied to them). Those elements are later reused for other event bars as you scroll. This approach is faster than removing and adding new elements. So seeing a bunch of b-released elements is expected. They are all display: none, and does not affect browser layout costs (not much anyway).

One easy thing you could try to improve scrolling performance in vertical mode is to turn off sticky events. Vertical mode cannot use native stickyness, because of how that is implemented in browsers it can only be used in horizontal mode. So instead it does programmatic stickyness on scroll, which is costly.

Try configuring your scheduler with

features : { stickyEvents: false }

and see if that helps.

[nagasain]

Thanks, Johan! I'll try the config you suggested for vertical mode. Do you have any quick tips to improve scrolling performance in horizontal mode?

And regarding 'b-released,' I get that it’s faster than removing and adding new elements. But to temporarily reduce DOM nodes, we’ve been manually removing these 'b-released' elements on the scrollEnd event and in the eventRenderer. Does this cause any issues apart from the remove-and-add concern, we didn't observe any issues till now, but just wanted to check?

[johan.isaksson]

Hi,

Yes I strongly recommend not doing that, the code that reuses elements does not expect them to be removed by external code. It might lead to event bars not appearing as you scroll.

For scroll performance in both vertical & horizontal mode, keep the code that runs on scroll in your app as simple as possible - eg. mainly the eventRenderer. Beyond that we would need some code to run and debug to give any more specific advice.

[johan.isaksson]

You can also check the settings used in the "bigdataset" demo, https://bryntum.com/products/scheduler/examples/bigdataset. Some of them help improve scrolling performance slightly (by disabling things that happen on scroll)

[nagasain]

hey Johan,

even with stickyEvents false, unfortunately we do not see any improvement in terms of memory consumption or reduction in detached dom nodes, gradually page tends to become slower as memory keeps increasing, and I understand the risk of removing .b-released class elements, although I was testing and couldn't find any bug of events not appearing as such.

As per scheduler library code, I see only removal of textNodes but not actual element or other elements inside the element, may I know the reason behind it?

If you see in the same big data example with the template I attached, after you scroll horizontally and vertically for some time, roughly 5-10 mins, tab memory keeps increasing and it will not be released. It keeps on increasing and almost reached more than a GB making page unusable.

Could you please suggest any additional approaches or techniques I could explore to mitigate this memory growth problem when scrolling through large datasets? I'd appreciate any insights or recommendations.

[johan.isaksson]

When events scroll out of view they are released (hidden), and when another element is scrolled into view a previously released element is used for it. The reason is that this approach is faster than removing and adding events. Thus event elements are seldom actually removed from the DOM.

If memory usage grows by only scrolling, it sounds like a bug. Perhaps you could check how many released events there are? Should not be a large number. For example by running $$('.b-released').length in console

[nagasain]

If memory usage grows by only scrolling, it sounds like a bug. Perhaps you could check how many released events there are? Should not be a large number. For example by running $$('.b-released').length in console

Yes, memory is growing as I scroll and .b-released elements count is also increasing, started with couple of hundreds and it crossed more tha 4.5k within 10 minutes of scrolling. My total number of events are around 500 and around 65 resources.

[johan.isaksson]

That sounds strange indeed, should not happen. I have tried to reproduce it by scrolling around in the bigdataset demo with 10K events with the event template you supplied, but I cannot get memory usage to grow and I only have 30 released elements after a few minutes. Also recorded heap snapshots and they show nothing out of the ordinary.

Please share how to reproduce this issue, preferably as a runnable test case that I can debug.

[nagasain]

In the same bigdataset demo, add this

scheduler.resourceColumns.fitWidth = true;

and try to scroll for a couple of minutes you can see increase in b-released nodes and also if you check browser task manager, overall tab memory and JS memory will be increased as you scroll.