IE8 performance issue

[jbadeau]

Hi Brian,

We are experiencing extreme performance issues with when 2.6.0 (or any 2.x version).

I have created a repo: https://github.com/jbadeau/when-2.x-ie8-performance

which demonstrates the issue.

basically when 2.x is used the app leaks about 20mb on refresh and load time is heavily impacted. IE8 becomes completely unusable in a moderately complex wire app in about 3 refreshes.

I hate having to support IE8 but I cant get rid of it yet :(

This is a very critical issue for us. If you need any additional info or help please let me know.

Cheers,
Jose

[briancavalier]

@jbadeau Thanks for the test case. One major difference in when 1.x and 2.x is that 2.x, in order to be Promises/A+ compliant, must resolve promises asynchronously. In IE8, when.js 2.6 falls back to setTimeout, but also uses a queue processing algorithm that minimizes the number of setTimeout calls. There will definitely be some small amount of slowdown due to that, but I definitely wouldn't expect it to be leaking.

I tried your example in a few other browsers and it doesn't seem to leak. The memory increases slightly on page loads, but then is reclaimed (when the garbage collector runs, presumably) periodically … over time, it looks quite stable in Chrome, FF, and Safari. I'll fire up an IE VM and take a look.

What are you using to measure the memory? Are you just looking at windows task manager?

[jbadeau]

Hi Brian,

This is only an issue with IE8, all other browser including IE9+ work fine. I am using "Process Explorer" to watch memory.

[briancavalier]

@jbadeau Cool. thanks for the additional info. This sounds like it'll be a fun one to debug, heh :/

[jbadeau]

Yeah, I had a quick look with the IE8 profiler but wasn't too useful for me. Im gonna have a look now with DynaTrace

[briancavalier]

Awesome, any additional info is certainly welcome :)

[jbadeau]

An update:

So I have removed the memory leak. This is a leak in dojo with their console shim. However the load time issue is still there.

I have seen that the memory consumption is very high (up to 3x) on a refresh. It looks like allot of garbage collection is happening.

The load issue only seems to happen in the runHandlers method (I commented it out).

I have tried setting the handlerQueue to null on unload but no change.
I have also increased the setTimeout to 3 seconds but no change.

I'll have another go at it today!

[briancavalier]

Interesting. Good to know about the dojo console shim (does it still use Firebug Lite?) I did a little testing as well, and my current theory is that this is probably due to the fact that wire tends to use a very large number of promises during wiring. So, when the app is starting up (i.e. page is loading, wire is wiring some initial specs), it is generating lots of short-lived promises that then have to be garbage collected.

A couple quick questions:

1. When you say 3x memory consumption, what exactly do you mean? For example, 3 x ?
2. Do you see the memory usage go back down after the 3x memory spike?

And here's something you can try. I created this issue-227 branch where we can do some experiments. It has a small change that keeps the handlerQueue from growing as much. Could you try it out and let me know what effects it has. I don't expect this to be a "fix", per se, but I'm hoping we learn something from seeing how it behaves compared to 2.6.0.

Thanks for working through this!

[jbadeau]

The dojo code in question is from the dojo/_base/kernel module. It basically fills in missing firebug console methods

"assert", "count", "debug", "dir", "dirxml", "error", "group", "groupEnd", "info", "profile", "profileEnd", "time", "timeEnd", "trace", "warn", "log"

with noop methdos so that code doesnt fail when no firebug or compatible console is installed. They still use firebug light for old browsers that dont have a console (eg ie6 ie7).

Q1. I mean that after the inital load the memory consumption could be 80mb, on referesh the memory usuage jumps to 240. At 240 the garbage collection kicks in and memory may drop to 60mb and then back to 240 untill the page loads. After the memory spikes, the memory returns to original 60mb.

I have also seen that there are allot of promises with wire but when 1.X handles this with no problem.

What is the behaivor if the queue cannot be trained in one tick? Are the handlers invoked again even if resolved?

Another thing; is it possible to have more than 1 concurrent setTimeout (drain takes longer than 0ms)? many setTimeouts have issues with memory? Perhaps using 1 setTimeout and clearing the curent one or using setInterval may help. I will try this out?

[briancavalier]

Ah, ok, so at least we know it is getting garbage collected. In 1.x, resolutions were not forced into a future turn, so the handler queue could be unwound in the current call stack. In 2.x, the handlers have to be queued until the stack clears (this is a Promises/A+ requirement), which means that the handler queue typically grows larger and lives longer in 2.x than 1.x. Or, to put it another way, because when.js 1.x violated the "wait until the stack clears to process handlers" requirement of Promises/A+, it could clear the queue more often--thus it never grew as large.

That all aligns with the theory that the large number of promises created by wire causes the spike.

Is the 240mb spike acceptable for your app? Or is it causing a problem (like crashing your app in IE!)?

I'd certainly love to reduce the memory usage, and I think it would take 2 things:

1. Reduce when.js's overall memory usage. There are probably some small things that can be done, and
2. Try to reduce the number of promises that wire creates. There's probably more that can be done here.

I'll create issues for those.

[jbadeau]

So the behavior of branch issue-227 vs 2.6.0 is:

2.6.0

• initial load takes 1 sec
• subsequent refreshes increases load time by about 200+ ms
• the size of the queue in the runHandler method ranges from 0-2

227:

• intial load takes 6 secs (6x vs 2.6.0)
• subsequent refreshes do NOT take longer
• the size of the queue in the runHandler method ranges from 0-32
• all versions use about the same amount of runHandler invocations
• I can understand that the 2.6.0 version is faster because it has less items to process (cpu time) but more importantly, less items on the event loop stack.

[jbadeau]

The problemis very severe for us. refershes go from 4sec inital load times to 2 minutes plus the ui is unusable.

[briancavalier]

@jbadeau when 2.7.1 has some perf improvements and reduces overall memory usage. If you have a chance, could you try it and let me know if it helps your situation (even if it doesn't completely solve the problems you're seeing). Thanks!

[jbadeau]

i feel the need.................the need for speeeeeeed :P