Support Forum

Hm.. perhaps it was added after 5.5.0 - try with 5.5.1?

Can you please test the performance w/o filtering but with sorting? I'm benchmarking on the reduced dataset, so numbers are different, I'm curious if the behavior in your app is matching.

Should still exists - its a publich method https://bryntum.com/products/gantt/docs/api/Scheduler/crud/AbstractCrudManagerMixin#function-suspendChangeTracking. Crudmanager as a mixin is added to the Project class.

Hm.. I definitely see 1 filter enabled in your app:

Some further checks revealed that its actually filtering that impacts the performance most, not sorting. My benchmarking for applyChangeset:

Raw: _3ms
Sorting: _8ms
Filtering: _157ms
Sorting + Filtering: _134ms

Does it match with your experience?

Thanks for the update, I've created a ticket to investigate: https://github.com/bryntum/support/issues/7320

Ok, those messages seems to trigger excessive data updates. Perhaps if that can be fixed, even performance with sorter will be acceptable (theoretically should be the same as applying sort manually as you tried).

After the deploy change I do see a different profile results. The timing of the individual applyChangeset call seems to be improved, but there's many of them, all triggered by some web socket message. You can also check why that happens.

Just a side note that WBS code is refreshed for every field change because of the enabled sorter (with enabled sorter we don't know if the change in "description" affect position of the node or not). If you can disable the sorter that might also improve the performance.