ngOptions slow in IE with large arrays

[a-b-b-a]

I have a 500+ element array which I want to bind to a <select> element.
In Chrome, this works fine, adding the array takes a fraction of a second.
In IE, it takes multiple seconds to add the array, during which time the UI is unresponsive.

Looking at timelines, it appears that Chrome recalculates styles after all <option> elements are added, but IE calculates styles and layouts after each <option> is added.

Chrome:

IE:

Maybe using documentFragments could fix this?

Plunker: http://plnkr.co/edit/ULtEHtcD5La4Ax7hd5kY?p=preview

[wesleycho]

A 500+ element array being bound to a select element sounds like a bad idea from a UX standpoint.

[rebornix]

Meeting with the same issue in IE. Per ng-options source code, we know currently Angular is trying to reuse DOM elements to reduce unnecessary DOM redraw.

function addOrReuseElement(parent, current, type, templateElement) {
    var element;
    if (current && lowercase(current.nodeName) === type) {
      element = current;
    } else {
      element = templateElement.cloneNode(false);
      if (!current) {
        // There are no more elements so just append it to the select
        parent.appendChild(element);
      } else {
        parent.insertBefore(element, current);
      }
    }
    return element;
  }

But can we leverage documentFragments when try to append new elements

parent.appendChild(element); // use documentFragments to cache these newly added elements

Then we can avoid the performance hit when select options vastly change. @wesleycho @Narretz pls let me know if this is acceptable.

I tested on my machine with 1000 items in select options, using documentFragment can reduce appendChildren calculation time.

Original code

Using DocumentFragment

[rebornix]

Even if we abandon DOM reuse completely and use documentFragment to recreate the new option list, the performance is still good like below

Update option list from 900 items to 1000 in IE 11.

Both deleting option element and appending new options in documentFragment are fast.

[Narretz]

Can you open a PR that uses documentFragment when appending new elements (without deleting option elements)

[jeffmath]

I ran into this exact same issue today with IE11. I had to remove my page's dropdowns from Angular's supervision and populate them using JQuery, instead, to get good speed on IE. ngRepeat was a lot faster than ngOptions (~3 seconds vs ~10, respectively) for two dropdowns with ~500 items each, but the JQuery approach takes less than a second. It's a shame to have to wire the dropdowns manually just to be fast on IE.

[seurimas]

Hopefully, this can be resolved soon, but here's a hack that defers DOM creation to JQuery for simple lists:

...
      function updateOptions() {
...
        options = ngOptions.getOptions();
        var hackyString = new Array(options.items.length).join("<option value='dumb'>dumb</option>");
        $(selectElement).html(hackyString);
...

This speeds up execution ~100x (2 minutes without versus a little over a second with) for a list 4000 items long. Judging by the path jQuery takes in IE11, generating the list with document fragments is a viable way to go, but I'm not familiar enough to create a real, long-term pull-request to fix.