Performance issue with thousands of items

[performancewanted]

I realize I'm being lazy and probably should implement some sort of autocomplete AJAX solution instead of using Chosen, but figured I'd report a performance bug with Chosen: When I pass in thousands of items (I've got a little over 5,000), it takes a number of seconds to open the dropdown and a few more seconds to type in the first couple of characters into the search field. This is on a Core 2 Duo desktop with several GB RAM to spare, so it isn't the hardware.

Instead of pointlessly wrangling with the existing code to try to squeak out more performance, it makes a LOT more sense to add an option that won't show any items in the dropdown until 'x' characters have been typed in as well as another option that only shows results when the number of matched items is less than some configurable threshold. As an example, let's say I set the threshold to 200 items and I want to not to even bother looking for results until at least 2 characters have been typed in. If a user types in two characters but 240 items are found, nothing gets displayed. The user then types a third character, which narrows it down to 15 items, so all 15 items are displayed. To keep the user informed, such a feature would display why there are no results showing (e.g. "Too many items found." or "Type 'x' more character[s] to get results.")

This is a better approach because no intelligent user is going to scroll through hundreds to thousands of items when they can narrow the selections by typing until the list gets small enough to manage. But it also might make sense to let the user show all the items anyway (depending on the list).

[tarciozemel]

Yeah, very well observed! I have about 10k options here...

Besides this feature, would be great a option to specify a delay to start the search. Example with both suggestions:

$('.element').chosen({
    chars: 3
    ,delay: 250
});

[pfiller]

#1339 made Chosen much, much faster. Give it a try!