| 3 | | It turns out that most of the time spent in sortable() relates to calculating the size of the 'items'. That's a pretty expensive proposition for large sortables, especially if all of the sortables are of uniform size. |
| | 3 | Each sortable has a full table of every other item in its connectWith containers. Probably the containers should do their own thing. This starts to get pretty bad even with only 3 containers, because you get 9 entries for each item. So that's probably priority 1, and could be fixed as part of a breadth-first search solution (ie, find the containers I'm intersecting with, then ask them about their items, rather than keeping my own cache). |
| | 4 | |
| | 5 | Beyond that, it turns out that most of the time spent in sortable() relates to calculating the size of the 'items'. That's a pretty expensive proposition for large sortables, especially if all of the sortables are of uniform size. |