Please find the attached sample code, which is a modification of one of the demo sourcecodes. It has a large dataset, but initial loading is fast and memory usage is acceptable. Impressive.
However when interacting with the scheduler (meaning: create new events, drag/drop some events, delete events) the memory usage rapidly grows and performance starts to get worse and worse. After about 10 of these interactions memory usage has multiplied by 4 and responsiveness becomes unacceptable.
Hi,
unfortunately, there is no any good solution.
Due to the current implementation, a performance of the timeline degrades quite fast with the number of sections displayed. Fixing it will require rewriting a big part of the timeline, which we are going to do, but can’t provide any eta.
However, there shouldn’t be memory leaks, at least to our knowledge. The memory should stabilise on some level. There will be peaks on complete redraws or during drag and drop, but eventually all allocated memory should be reclaimed by the garbage collector after a while.
So far the only possible way to speed up such config is to limit number of sections displayed in a timeline
Hi! Is this still an issue or the code is already be rewritten to improve the performance of the timeline?
I will need to have a timeline with +/- 150 sections.
Get a guaranteed answer from DHTMLX technical support team
under the most suitable support plan