Speed up reorder when a lot of rows shown

[kieranhaycock]

Hi

Ran into a performance problem when reordering a table with more than 300 rows. It actually gets slowly worse the more rows added.
After a bit of digging we found what was causing it to be slow:

The inserting causes the drag to not be as smooth as you would hope. If you are dragging a item up past 100+ items it can get very annoying.

The solution we came up with was to move that logic into a debounced method, meaning if the user stops dragging for x milliseconds it then calls the function. This has greatly improved the performance for dragging rows and is a lot more scalable.

However, I thought I would post on here to see if we were missing something?

[AllanJard]

That sounds like a nice option. I do like the live updating as you drag when there are just 10 rows per page or something like that, so I'd be loth to remove that, but if we could mix the two somehow, that would be good.

Is it the insert or the cache positions that is causing the performance issue? I'd guess the positions is the slow part.

[kieranhaycock]

Yes, I agree the live updating is good. We tried to keep it in there as it makes it so obvious where the row is being added. Yes, I'm sure the main performance issue is the inserts, I will double check the cache call now and let you know. I just assumed (correct if wrong) that if the cloned row wasn't inserted then it didn't need to cache the data.

We only started seeing this issue when our end users started to have more than about 50 rows and because of multiple reasons paging is not an option. I'm sure we could end up having some config to enable/ disable the debounce.

[kieranhaycock]

I can confirm that it is not the cache call, only the Inserts that were causing performance issues.