Ticket #2528770 (accepted defect)
Reporter Garrett Conaty |
Opened: 04/12/10 Last modified: 09/19/12 Status: accepted Type: defect |
Owner  Dav Glass |
Target Release: BACKLOG Priority: P3 (normal) |
|---|---|---|---|
| Summary: | Sortable performance decays linearly with more elements | ||
| Description: | Test case is the sortable-multi-full.html example. Modify that to have about 40 list elements. The drag operations stutter worse the more elements in the list. Doing a quick 'perf' with Firebug, it However, dynatrace (which I've found much more accurate for perf) reports that nearly all the time is being spent in offsetHeight, offsetWidth, and getBoundingClientRect (which would explain the Tracing a bit more this seems to be in the check to '_handleTargetOver' via a Y.each which could explain the performance degrading (linearly) with more elements. |
||
| Type: | defect | Observed in Version: | 3.1.0 |
| Component: | Sortable | Severity: | S3 (normal) |
| Assigned To: | Dav Glass | Target Release: | BACKLOG |
| Location: | Library Code | Priority: | P3 (normal) |
| Tags: | Relates To: | ||
| Browsers: | Firefox 3.x - Mac,IE 7.x | ||
| URL: | |||
| Test Information: | Test environment is an octo-core Mac Pro. |
||
Change History
|
Posted: 04/14/10
|
|
Posted: 04/16/10
|
|
Posted: 05/10/10
First run patch landed here: |
|
Posted: 05/10/10
Refs #2528770 - Added some code to make drop targets faster, I can now use 500 sortable items with decent performance |
|
Posted: 05/10/10
Refs #2528770 - Added some code to make drop targets faster, I can now use 500 sortable items with decent performance |
|
Posted: 06/29/10
|
|
Posted: 10/14/10
|
|
Posted: 12/31/11
Just commenting to bump this for priority I hope. Here are a couple fiddles to compare jQuery Sortable vs. YUI 3.4.1 Sortable. In IE7, the YUI one is noticeably slower. jQuery - http://jsfiddle.net/SMMVS/ |
|
Posted: 09/19/12
Moving from 3.NEXT to BACKLOG. |
Jenny Donnelly
Debugged and hopefully gleaned some more information. Looks like for a typical drag/drop case, _activateTarget does cache the region for the drop targets and that cache is used in the intersect on the dropMove.
However, Y.DD.Delegate sets 'useShim' to false for all of its subnodes, so when sizeShim gets called as part of _activateTarget, no data is cached. For this example, this forces the region to be calculated on all LI elements on EACH mousemove.
Perhaps the optimization would be to cache the region of the delegates anyhow, and then detect if there have been any structure changes (DOM insertion, css, etc.) and recreate the cache.
I believe that the first sortable example actually did this via syncActiveShims, though it seems it would only have to occur when items in any list are 'bumped' out of the way as part of the drag operation.