#4410 closed enhancement (notabug)
Super major speed enhancement for sortable with large lists
| Reported by: | cardmagic | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 1.8 |
| Component: | ui.sortable | Version: | 1.7.1 |
| Keywords: | speed performance sortable | Cc: | |
| Blocked by: | Blocking: |
Description
After much digging around, I found a mis-placed call to _refreshItems which significantly slows down sortables with large numbers of items. _refreshItems does not need to be called during the movement of items as it is currently, but rather it should be called as soon as it has reached a new location. Attached is a patch.
Attachments (1)
Change History (6)
comment:1 follow-up: 2 Changed 14 years ago by
comment:2 Changed 14 years ago by
Replying to cardmagic:
Found a bug in speed.patch... but found a work-around... will submit shortly as speed2.patch
When someone moved the refreshItems call to mouseCapture, it seriously slowed down the entire repositioning, so I moved it back to the _mouseStart method.
comment:3 Changed 14 years ago by
Instead of naming the patch speed2.patch, I just replaced speed.patch with the correct patch file
comment:4 Changed 14 years ago by
| Milestone: | TBD → 1.8 |
|---|
Performance improvements are welcome. Patch needs testing.
comment:5 Changed 13 years ago by
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
Patch isn't working, since this move from mouseCapture to mouseStart heavily destroys some functionality: If you add new elements to a sortable list, say via an ajax call, they're automatically valid draggables because of the check being there in mouseCapture already - if it wouldn't, they wouldn't be considered a target, and therefore the drag fails.
Found a bug in speed.patch... but found a work-around... will submit shortly as speed2.patch