MultiSelect Performance Gets Worse the More Often Its Menu is Opened/Closed

[Ri-gers]

Initially, once the component is clicked to open its menu, it opens immediately. However, the more often this is done performance drops step by step... This also applies to a little item pool (tested with 20 options). So opening and closing the Select component makes it progressively slower - even if no items are de/selected at all.

[vegegoku]

This was indeed a very weird and difficult one to tackle, There was nothing obvious in the code that could lead to such performance impact, even the profiler didnt show anything useful that points directly or indirectly to the cause of the issue other than showing that calculating styles was taking way longer every time the menu is opened. not only that but apparently it was a chrome issue that didnt show up in firefox. check the screenshot

With a lot of testing, and after touching every place possible that is related to the process of opening/closing the menu I decided to use the code elemenation approach which lead me to find that the z-index is the problem.

We are trying to tackle the problem of component stacking in the viewport by assigning new z-index to any modal/popup that opens in the UI, including dialogs, menus, tooltips and popovers..etc, so we use an incremental approach for the z-index. this was supposed to work well, and it used too, for some reason in chrome if we keep incrementing the z-index style computations starts to impact the performance, I am not sure if this is a new bug in chrome or not since I could not find any thing related to this, firefox is consistent and does not have such issue. seems like chrome might have a leak there were z layers are not being freed when elements z-index is changed, in the drop/menu case this become worse as we add more options ofc.

As for the fix and since domino-ui cant actually control or limit the stacking (user opens a modal, the modal has a select, there is also tooltip, and popover, the popover opens another modal, the modal shows a message dialog..etc..) there is no a complete fix for this, plus I believe this is still a chrome bug (imagine this happens for modal dialog with tables and thousands of elements , then we keep open and close it and needs to change its zindex for some reason, just few times are enough to kill the page performance). but to make sure that this does not have a big impact on performance I have reduced the instances where we need to actually increment the z-index specially for menus, tooltips and popovers, those are the components that we normally show/hide or open/close the most.

after I push a fix I would love to see some more testing and feedback on this.

[Ri-gers]

Wow very interesting finding, thanks a lot! I will test this once 2.0.4 is available as improvements to MultiSelect are very welcome and crucial. I just stumbled across this problem because I experience performance issues in general with MultiSelects containing up to ~1.3k items or less, but normally they won't get opened and closed several times.