I have an app with multiple tabs. Under each tab it is a large list with models and group helpers and etc. I did a lot of optimization so each table cell is not even an ember view.
I found that when the list grows large (50+ items), switching between those tabs become slow in IE9. It works very well in IE10+ as well as other browsers. Can anyone explain a bit what is the expensive thing during route transition and shed some light on how to fix this?
How to repro this issue (IE9 with 4GB memory on a virtualbox):
1) visit discuss.emberjs.com. Scroll down to load maybe 200 hundred items.
2) Click "Categories" tab. Notice that it takes a few seconds to load the page.
If in step 1), we do not load these many items, the tab switch is very fast.
The experiment is to transition away from a list with about 100 items. And it takes 5-7 seconds to finish the transition on IE9.
Here is the result:
“empty” function refers to this function in metamorph:
empty: function(view) {
var _childViews = view._childViews, len, idx;
if (_childViews) {
len = _childViews.length;
for (idx = 0; idx < len; idx++) {
_childViews[idx]._notifyWillDestroyElement();
}
}
view.domManager.empty(view);
},
it seems it is caused by “removeChild” being slow in IE9. What is surprising is that it looks when we are doing a route transition, we are manually removing all existing views one by one from the DOM and then transition to the new state instead of just destroy them at once.
Can we think of any workaround? Like some way to trick Ember to do an O(1) transition instead of this O(N) thing (N being the # of items) that is seemingly happening?
I find that during transition if I hide the DOM with the lots of element would dramatically boost the performance on IE9 …
Just to contribute the optimization:
reopen router and update handleURL function:
handleURL: function(url) {
// Hide the crazy heavy DOM,
$('.heavy_dom').hide();
var args = arguments;
var that = this;
Ember.run.next(function() {
return that._doTransition('transitionTo', args);
});
}
We honestly haven’t been too concerned with performance in IE9 (we don’t get many complaints about it) so we haven’t noticed this, but it is interesting.
I wonder if at this point it just makes sense to wait for HTMLbars before spending more energy on this older browser.