Extremely poor render performance in IE 11

[kvanbere]

IE 11 is taking between 100x and 1000x longer than Chrome and Firefox to render pages in our app (what takes 10's of milliseconds in the other browsers seems to end up taking seconds). This is more of a meta-issue to discuss how we can make this less extreme.

Also refer to the benchmarks here, where vue.js sometimes wins/ties over mithril whereas it gets easily beaten in other browsers (and angular is as fast as Mithril in IE9? huh?):
http://jsperf.com/angular-vs-knockout-vs-ember/351

Definitely don't feel like I'm blaming poor IE performance on mithril! It is incredible how fast it is already, and we're absolutely spoilt as it is. /But/ IE-specific optimisation is something worth researching.

[kvanbere]

I will follow up with some profiling results.

[lhorie]

Thanks @kvanberendonck

FYI, @pygy was also running into similar quirks w/ Angular and IE9 for a todomvc benchmark that we were working on (basically it wasn't actually measuring anything meaningful). There's definitely something weird going on about the combination of those two and javascript-based performance measuring tools.

[lhorie]

quick update: I tried running the TodoMVC benchmark in IE11 and I'm not experiencing the slowdowns there

http://lhorie.github.io/todomvc-perf-comparison/todomvc-benchmark/

[kvanbere]

Did you compare with another browser like Chrome?

I tried profiling but couldn't pinpoint any useful information using the inbuilt tools. The profiling results are mostly unhelpful, apart from telling me that one of the biggest (but yet still small, apparently only 2%) overheads was insertBefore.

Internally the issue is shockingly noticeable; we've got a couple of screens with massive nested keyed arrays, around 75 in size each. In a particular scenario these get rendered about 5 times in succession and the sum of these renders take approximately 2 seconds in IE and are visually instant in Chrome and Firefox.

I posted this ticket because I thought the speed difference was curious and worth looking into, but if nobody else can replicate it then I apologise.

[kvanbere]

Actually, doing some quick tests, I'm willing to believe that the todomvc benchmark showcases that renders of long lists of items take long enough (~200ms) that, repeated and padded out 5 times, could easily reproduce the render times (2 seconds) I'm seeing here. I can't confirm until I get access to a Windows machine again.

[kvanbere]

Interestingly also, vuejs is 30% faster than Mithril on Safari.

[zachsnow]

I ran into a similar issue with AngularJS (angular/angular.js#8533); we tracked our issue to a security update for IE (KB2962872). Uninstalling that patch brought performance back up to normal.

[kvanbere]

Intriguing, I'll try uninstalling the update and seeing what happens.

[zachsnow]

A very recent update seems to have fixed the issues I described, at least in initial testing. See: http://support.microsoft.com/kb/2991509

[kvanbere]

Yes, I just tried uninstalling KB2962872 and unfortunately the issue remains.

[zachsnow]

Ah, sorry I couldn't have been more helpful!

[kvanbere]

We've noticed IE11 is not as bad if we manually batch renders. Other browser performance not really affected by doing this.

Maybe IE11 does not know how to auto batch?

[lhorie]

Hmm intriguing. IE11 should be using requestAnimationFrame/cancelAnimationFrame. Is there some caveat to those functions there that I'm not aware of?

How are you going about the manual batching? Maybe I could take a look at how the core auto-batch is different.

[kvanbere]

Well, (and excuse me if I misled you by saying we manually batch) we have a socket that at a particular time will spawn around 100 messages in a small period of time. On the receiving of a message I call m.startComputation and m.endComputation when I'm done processing it. Every browser except IE was performing snappy with mithril, which is a performance miracle, really.

To fix IE, I added a system by which I removed m.startComputation and m.endComputation and programmed the system to render on only certain types of important messages, thereby achieving a batching effect with the messages inbetween. So, now I'm not trusting the browser, and just explicitly calling m.redraw. This happens about 5-10 or so times in comparison with the existing 100 start/end pairs.

This doesn't give a noticeable performance benefit on Chrome or Firefox (in both cases, they are lightspeed instant), but IE went from taking 3-4 seconds to fully render this one screen to being virtually instant like the other browsers.

So, I would conclude from this, that IE seems to want to do a full redraw for every start/end pair while the other browsers are quite happy to perform it asynchronously, maybe?

[lhorie]

FYI, I pushed a tweak to origin/next for older IEs that shouldn't logically affect IE11, but that may help this issue (you can never be sure with IE)

[KasperTidemann]

For the record, I'm seeing the same performance differences. In my test setup, I have a view that returns the following code:

return m('div', { class: 'test' }, [
  m('div', { class: 'more test' }),
  m('div', { class: 'even more test' }, [
    m('p', 'Hello, there!')
  ])
]);

Rendering 1,000 rows of the above view takes approximately 300ms in Chrome on a desktop, 2 seconds in Internet Explorer 11 on a Surface and roughly 2 seconds in Mobile Safari on an iPhone 5.

There is indeed a striking difference between 300ms and 2 seconds. However, I'm not sure if this calls for immediate action. Rendering that much DOM on page load is not advisable to being with. I tried implementing infinite scrolling that had 10 rows appear at a time and for such (more sane) amounts of renders per cycle, you just don't notice the difference in render speed.

Still, when dealing with huge amounts of stuff in the render pipeline, the performance difference is noticeable.

[jmventura]

why would you have a 1000 rows of that on the DOM in the first place? It’s going to make things slow anyway...

[KasperTidemann]

That's exactly what I'm trying to say: you shouldn't.

[kvanbere]

We don't render as much DOM as that: we render only about 100 elements, but some are indeed deeply nested.

The performance difference is still there, but manual batching seemed to remove the magnitude of difference we were noticing. It now (although no longer measurable) feels somewhere in the order of 10's of ms instead of the previous 2-3 seconds it took.

So, I don't think I was actually hitting a significant perf issue with IE: I was just taking for granted the auto batching behavior of the 'better' browsers. @lhorie will be pushing a patch which might make this better automagically, maybe.

On a side note, I had some rarely executed code which didn't actually contribute to the perf issue at all, but it called m.redraw() directly, because at the time I thought calling start/endComputation directly after each other would be pretty stupid. I dug into the source code for mithril a little bit and actually replaced this pattern with the latter because I don't think mithril takes into account pending asynchronous redraws using the former? In the long run I had a small decrease in render count per screen initialization (from 4 to 3) by doing so, but this difference is not as noticeable as our initial batching implementation.

[lhorie]

I've done a bit more testing and while IE does run slower than other browsers, it's not 100's or 1000's of times slower. Given that no one else is complaining about this, I'm going to assume there's no actual issue, at least not under normal circumstances.

[Li-ReDBox]

I just noticed this delay in IE with simple array pushing when I was doing study. On page, I used v-for rendered a list of objects (based on the grid example). Then I push a new object to the array through console. It will take 1 - 2 seconds to get updated. What I found interesting is, when I added console.log(Date.now()) in timerFunc, it will update "instantly" to my eyes. Strange IE!

[gyandeeps]

Perf for mithril vs reactjs on IE vs chrome

Use case

We have created our own framework based on our needs but then started looking for vdom implementation to support that. Thats is when we started using Mithril.

What we use from mithril:

• m - to create dom elements
• m.render - to mount the main node

What we used from reactjs for this test:

• react.createElement - to create dom elements
• ReactDOM.render - to mount the main node

Our framework is built in a way where its easy to replace the element creation and mount portion logic with any external implementation. 😄
Here is what we saw when we render a table which uses divs with 3 columns.

IE-10

Table Rows	Mithril	ReactJs
100	37-41	38-44
500	162-165	147-166
1000	335-355	285-305

Chrome

Table Rows	Mithril	ReactJs
100	27-35	57-62
500	85-91	176-185
1000	125-175	295-315

Note:

• All times are in ms.
• Did 15 runs each with manually refreshing the browser.
• 1000 rows were basically just to get some numbers and its not a real usecase.

Observations

• Mithril is way better on chrome with a great margin.
• Mithril is slightly slow on IE-10 but its very close
• Based on the margin its definitely something to do with native stuff with IE

I just wanted to share my findings. Now i am really curious on what might be gng on inside IE.