Open Bug 839816 Opened 11 years ago Updated 2 years ago

Make next-tick mechanisms like postMessage faster

Categories

(Core :: DOM: Core & HTML, defect, P5)

x86_64
Windows 8
defect

Tracking

()

UNCONFIRMED

People

(Reporter: d, Unassigned)

References

()

Details

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130201065344

Steps to reproduce:

As per bug #686201, Firefox's "schedule something asynchronously for the next tick" mechanisms are slow, compared to other browsers (and in particular compared to IE10's setImmediate).

In the linked demo, wall-clock approximate timing gives

Firefox with 0ms setTimeout via "dom.min_timeout_value = 0": between 1.8 and 7 seconds
Firefox with postMessage hacks: between 1.5 and 6 seconds
Chrome with postMessage hacks: between 1 and 1.3 seconds
IE with setImmediate: between 0.4 and 0.5 seconds

The need to schedule something to happen in the next turn of the event loop, but as fast as possible, is common in e.g. promise libraries.
So I just profiled that testcase.  A good bit of the time is spend painting all those bars.  In fact, if I run the testcase as-is I see times in the 800+ms range, but if I just make the TestDiv div visibility:hidden I get numbers closer to 450ms...

Worth checking the numbers compared to IE with the TestDiv set to visibility:hidden and also display:none so you can tell apart things like "event loop is slow" and "event loop has events in it that are slow to process".
Now I'm just not sure what to think:

http://jsperf.com/setimmediate

This bug might be invalid.
Well, no matter what there's a bug here about slow painting...

That said, what sort of numbers do you see on Windows on your jsperf test?
I don't believe jsperf is a good way of obtaining numbers. When I came up on the jsperf page, Fx was a clear winner (even if it told that Fx 21 > Fx 22 > Fx 23, FX 23 still had 4x much perf as any Chrome version).

I have probably a very different computer configuration (Intel quad core proc / 16Go RAM)... After I tried Fx23 & Chrome 28 I just had completely opposite results as the ones that were registered previously. Chrome 28 twice as fast as Fx 23 on my tests.

We need to devise a better way to find out if there is something or not. But jsperf won't tell us a thing.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.