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)
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.
Reporter | ||
Updated•11 years ago
|
See Also: → setImmediate
Comment 1•11 years ago
|
||
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".
Reporter | ||
Comment 2•11 years ago
|
||
Now I'm just not sure what to think: http://jsperf.com/setimmediate This bug might be invalid.
Comment 3•11 years ago
|
||
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?
Comment 4•11 years ago
|
||
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.
Comment 5•6 years ago
|
||
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
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•