Can you also please provide the OS details to reproduce the issue ?

Also please provide the sample URL so that we can try it at our end ?

Hi,

This issue is happening for our production system and we cant share the URL for this. 

It happens for any OS configuration for a bulk load on any drop down.

Thank you for providing more feedback. Adding requester "pucchakayala@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi,

Is there any update on this. Most of our partners are facing this issue currently.

Hello,

I've just sent an email to the owner of this bug, and wanted to also include those comments on this issue. We have produced a demo of the behavior here: https://chromiumdemo.build.itransplant.net/.

Additionally, we have captured video of the behavior in Chrome 50 here: http://screencast.com/t/2tYDrlInk (note how there is very little time spent processing), while in Chrome 51 here: http://screencast.com/t/jT074W6I  there is a significant amount of time where the UI is completely locked up.

I have attached JS timelines captured in Chrome 50 and 51 (they had to be zipped due to the max attachment size).

Please reach out with any questions you have as this issue is having a very heavy impact on virtually all of our clients who have upgraded Chrome.

Thanks!

Deleted: chromium_bug.zip 2.5 MB

chromium_bug.zip 2.5 MB Download

Could you produce a trace as per https://www.chromium.org/developers/how-tos/submitting-a-performance-bug and attach it to this bug? Thanks!

I vaguely remember a recent fix for removeChild... Can you try the canary and see if it is still so slow?
It installs side by side with stable Chrome, but it updates almost daily with a very recent (and not so tested) Chrome -
https://www.google.com/chrome/browser/canary.html

Also, as a quick workaround, since adding options is much faster than removing them, perhaps clear the contents of the <select> at once (selectElement.innerHTML = "" or using jQuery - $(selectElement).empty()) and re-add the options instead?

As requested, here is a trace I just took in chrome 51.

Deleted: trace_Tue_Jun_14_2016_9.55.14_AM.json.gz 5.8 MB

trace_Tue_Jun_14_2016_9.55.14_AM.json.gz 5.8 MB Download

@phistuck: The performance is the same in Canary, although the initial load of the select box works somewhat quicker. 

Regarding using $(selectElement).empty(), we already invoke that prior to adding the new elements to the list (I annotated the source here):

function bindContact1() {
        $.getJSON("contacts.json", function (data) {
            var contacts = data['contacts'];
            $("#dropDownContact")
                .empty() // empty this list and then add the null element.
                .append($('<option></option>').val(null).html("------"));

            //Append each data from the contacts.json
            $.each(contacts, function (key, value) {
                var option = $('<option />').val(value.id).text(value.name);
                $("#dropDownContact").append(option);
            });

        });
    }

Thanks for the idea though.

Sorry, that was a bad advice, because $().empty() calls removeChild. I thought it was just emptying the innerHTML.
So using selectElement.innerHTML = "" (or $jQuerySelectElement[0].innerHTML = "") should really speed this up.

@phistuck thanks for the ideas, but unfortunately they didn't help out the performance issue in Chrome 51 or Canary. 

Hopefully there is a way to address the core issue of this performance regression in Chrome.

Sorry, I should have checked that before giving you the advise. :(
I guess behind the scenes, setting innerHTML = "" goes through a similar code path as removeChild and thus remains slow. :(

It appears that someone else has logged a similiar issue here (possibly a duplicate of this issue): https://bugs.chromium.org/p/chromium/issues/detail?id=620142.

Merging into that one, since it has a smaller and more reduced test case.

I got the same exact issue, what took 100ms before takes now 4000-5000ms to remove few hundreds of <option> in a <select> menu. Our system became so slow that I had to bring that quickfix as a work around (replacing the whole select with another one similar but with the new values) :

var replacingSelect = '<select id="foo"><option value="0">Some value</option></select>';
$('#foo').replaceWith(replacingSelect);

Adding <option> itself isn't an expensive operation, it's very specifically emptying (or refilling) a <select> object with innerHTML and removeChild() methods. Of course.

Yep, we know, see the issue into which this issue was merged.