Speed of chosen

[truckingsim]

We are using chosen heavily in the admin section of a new site we are building. It is used inside of a reveal modal (from Foundation 3). It is also being tied in with knockout for updating the data.

All this is working, however sometimes it takes up to 10 seconds for chosen to load completely. 4 of the fields have 500+ elements each (loading from the same data source). 3 of them have 3 fields, a few more have a few hundred elements, and at least one has over 1,000.

Is there any way we can speed it up? It almost seems like it is being destroyed and recreated every time we open the reveal. We have big data sets and its only going to get bigger.

[kenearley]

@truckingsim I feel your pain. We are currently focused on performance. Hopefully, we will have some improvements soon.

[oli206]

Hi, I'm on the same situation. I'm using chosen on a page that has many selects containing about 3000-4000 options. If I don't load chosen, it's quite fast, but loading it is taking all the time. The funny thing is that all the selects share the same options, though chosen needs to be loaded for every one.

Is there something I could do here to avoid loading the same exact options every time? I've seen some libraries like Kendo that allows you to use a "data source" that is shared among all the combo boxes, but I'm not sure if something like that would work with Chosen.

[truckingsim]

@oli206 what we decided to do was initialize chosen on all the fields but leave the selects empty. We then hide chosen and put a box of basically their pre-selected options (if there are any, or a message that says none are chosen). When they click on this box we then load that specific select fields options and then trigger a chosen liszt:update for that specific field.

It is far from optimal, but it did bring our load speeds of the modal from 5-10 seconds to 400 milliseconds. Storing information in a native javascript array was fast enough on load as well which is where we get the information to load the select field. If all your fields have the same information it should be even easier.

As for loading 3000-4000 options at one time:

I don't know exactly how chosen works but it may be better to say load 500, trigger a liszt update, set a timeout of say 15 milliseconds to let it catch up and call your load function again and load another 500 and trigger a liszt update. If chosen only loads in new fields instead of emptying itself all the way and filling it back in, this may be quicker. But I'm honestly not sure how chosen handles new fields so I could be wrong with this one.

I still feel this is an issue so I'm leaving it open, these are band-aids to a real problem not fixes.

[oli206]

Thanks a lot for your answer @truckingsim , i was thinking in trying something like what you said in the first paragraph but i wasnt sure that it would work so i didnt do it in the end.if you got those results though, ill give it a try :)
There is something that I dont understand, when you say "we hide chosen and put a box" you mean that you are manually creating a select and then you hide it and show the chosen one? If thats the case, im wondering how are you getting the exact same look (size, padding and everything) of the chosen box in your box. Are you loading chosen in this "fake" select too or are you manually styling it through css ?

Regarding the 3000-4000 options, i dont understand how loading them in intervals would help?

[truckingsim]

@oli206 We literally hide the chosen field with $('#IDofSelect_chzn').hide() and when we need it $('#samething_chzn').show(). The box we then put on top of it is this ugly grey box that has a

list of their pre-selected tags (this is for an admin panel, which multi select on all the chosen fields). When they click on that big ugly grey box it runs this:

        var g= $('#g');
        var arr = categories.g;
        var len = arr.length;

        for(var i = 0; i < len; i++){
            g.append($('<option/>').val(arr[i].Name).text(arr[i].Name));
        }
        g.val(self.showG()).change().trigger('liszt:updated');
        $('#G_chzn').show();

With the appropriate jQuery selector, categories, etc... selected for each one. We've found this to be quicker and since its on the admin side of things not need to look beautiful. We would never do this on a public facing side. We are needing a similar feature there however, so I've been working on a custom thing that works basically like chosen (in how it displays multiple selections, floating elements, etc...) except it pulls from a remote source. This is to save speed on the front end.

Hope you can get something figured out, slow pages are no fun!

[truckingsim]

I missed your last question the interval one:

so this is entirely dependent on how chosen works but imagine this:

instead of trying to create 4,000 Dom elements at once and load them at once you created say 3. You appended them to your document, waited 10 milliseconds and did another 3. Repeat this 1,000 times and you've now given the browser 10 seconds to to load 3,000 elements. What you have also done though is you let the browser release the memory and CPU cycles it used to create those Dom elements. Instead of one big push you break it down into many micro pushes over a longer time. Now 3 every 10 seconds is a little slow, so say you did 10 every 10 milliseconds for 300 times. So now you've spread out that loading to 3 seconds which isn't bad if your page was freezing for longer than that. You would obviously need to play with these numbers to get a good speed/memory ratio.

Now, this only works if chosen appends new elements on trigger(liszt:update). If it rebuilds the list completely on that trigger than this is completely useless. So what else can you use this for?

well lets go back to my tags I've been talking about, we have a "management" system where you can edit/add/delete/view these tags in a scrolling div. So lets say you chose the category with 2,000 tags. Well now I need to load all those tags as divs inside of the container (one tag on each line, makes for easily styling). Throwing 2,000 append statements at one time to the browser here would take 30 seconds to load. So we added my interval fix and here we did 3 every 10 milliseconds. This makes for an extremely smooth scrolling loader, which lets the user scroll through the list while its loading without any lag. We went from 30 seconds of lag to none, and its because your letting the computer run small calculations many times over and over, and release the memory it needs to do this instead of everything at once.

let me know if you have any more questions and if you do try this let me know if it works!

[pfiller]

#1339 has been merged as of v.12.0 and it smokes. In my testing, Chosen seems fairly performant even when there are several thousand options I suspect there is still room for improvement, but this is no longer a burning problem. Thanks for the discussion, all.

[truckingsim]

Thanks for looking into this and will def look into v 12.0 hopefully we won't have to do these wonky workarounds anymore!