Slow with large lists about multiselect HOT 8 OPEN

Hi, pls see Yanick's fork at http://github.com/yanickrochon/multiselect/. He did a lot of improvements, and also implemented remote (ajax) list population. I'm planning to merge back most of his changes to my repo as soon as I can get some time together.

Cheers,
Michael

from multiselect.

Thanks Mike!
I had to reopen my gedit with that file again this week, as I need to replace the very first version of that widget with search capabilities with a more recent one. I did a rewrite of the droppable/sortable, but it's not quite functioning completely when both lists are sortables, but I think I'm on to something there. Anyway, using the it as it is, works farily well. ...moving on....

To the the op (whaz), you cannot save a markup for this widget as it relies on dynamically bound events and other data cache. For an extensive list, that why I had to add the remote call feature because I was on the same track as you. The script is farily easy to use, and definitly customizable. Good luck with that!

from multiselect.

It extremely slow with a list of 1175 items, running the latest version.

from multiselect.

yes, this is an issue that has been talked many times before. The markup and the number of events to bind to each item is too excessive for lists with extensive number of items. This is why a "Search" was implemented to populate the list will smaller chunk of items per search. I personally calculated that a list with 500 item did fairly well in most browsers (especially IE, the slowest of them all)

The initial design did not take in consideration lists greater than a few hundreds. Perhaps, if someone is interested, a better implementation would be to use a data model as backend and display only the visible items inside the viewport (like SlickGrid does) ... but this would require rewriting much of the code, and would probably be for a next major release of the widget... anyone up to the challenge? :)

from multiselect.

I hear yah, unfortunately my jquery experience is a little lacking to take up the project. Time is also not something on my side right now. I wonder how hard it would be to tie in to
the scroll bar and implement some type of scroll based paging mechanism.

from multiselect.

Hello, link provided above doesn't work anymore,

are there any plans for this project or has it been stopped?

from multiselect.

Wouldn't it be far faster if it used composing HTML+innerHTML and jQuery.delegate?
I haven't profiled it though.

from multiselect.

I did some profiling in Chrome and found that if I removed the hide() in _getOptionNode and the show() in _populateLists things were much faster, without any obvious impact on the widget. Let me know if I've done something bad! :)

from multiselect.