Closed
Bug 576688
Opened 14 years ago
Closed 9 years ago
IM: Performance on "new" JS A* benchmark somwhat volatile and between 30% and 100% slower than v8
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: bzbarsky, Unassigned)
References
(Depends on 1 open bug, )
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
text/html
|
Details |
See url in url field. Relevant numbers (moo branch has fix for bug 576398): m-c: 491ms v8: 167ms moo: 1085ms
Comment 2•14 years ago
|
||
Current numbers with a TM nightly build from today: Chrome: 147 ms Safari: 282 ms TM: 371 ms JM+TM: 421 ms JM: 428 ms Although still slower than TM and competition, this is much better than the numbers bz posted two months ago.
![]() |
Reporter | |
Comment 4•14 years ago
|
||
That bug isn't really related to this bug. Sayrer's A* benchmark is totally different code (and structured very differently) from this one, last I checked. What I want to know here is .... why are we not doing at least as well as TM? Do I need to file a separate bug on the heuristics fail here?
blocking2.0: --- → ?
Depends on: 580468
![]() |
Reporter | |
Updated•14 years ago
|
Keywords: regression
Updated•14 years ago
|
blocking2.0: ? → -
Comment 5•14 years ago
|
||
JM+TM runs this in 136 ms. Chrome and Safari are much faster (18 ms and 48 ms). @bz: do you know what causes this?
Comment 6•14 years ago
|
||
To clarify, the reduced test shows that ctx.fillRect is very slow. I can profile but I'm a bit lost in layout and painting, I don't know what numbers are reasonable there.
![]() |
Reporter | |
Comment 7•14 years ago
|
||
Jan, on which OS? I can confirm what you see on Mac, but graphics stuff can be much different on different platforms. That testcase is the same size as the actual benchmark? So it's costing us about 100ms of slowdown via Chrome, right? The rest of the difference (and the JM+TM vs TM difference) are JS eng? We really need to look into making fillRect on canvas faster; whether we make cairo faster for rect fills, or whatever. And maybe we should particularly special-case 1x1 rects, if possible... Sites tend to use them when they should just use imagedata. :(
![]() |
Reporter | |
Comment 8•14 years ago
|
||
Oh, and the FillRect profile shows the usual: us converting the whole thing to a DrawPath call and then _cairo_quartz_surface_fill spending forever in state setup and restoration, calling CGContextDrawPath, etc.
Comment 9•14 years ago
|
||
(In reply to comment #7) > Jan, on which OS? On OS X.. > That testcase is the same size as the actual benchmark? So it's costing us > about 100ms of slowdown via Chrome, right? Both use a 100x100 canvas. But in the original benchmark there are even more ctx.fillRect calls, to draw the path, etc. If I comment out all "ctx.fillRect" lines in the benchmark it's at least 160 ms. faster. Chrome gets 50 ms faster, so yeah I suppose this may win at least 100 ms here. > The rest of the difference (and the JM+TM vs TM difference) are JS eng?> If I comment out the fillRect calls, JM+TM is still 50 ms slower than Safari, but TM is only 5 ms. slower. I think most of this is in the JS-engine, but I haven't measured that yet. Do we need a new bug for fillRect perf?
![]() |
Reporter | |
Comment 10•14 years ago
|
||
For reference, bug 601176 was filed for the fillRect. If you comment out the canvas style sets, btw, how does performance look across the browsers?
Comment 11•14 years ago
|
||
(In reply to comment #10) > If you comment out the canvas style sets, btw, how does performance look across > the browsers? Chrome: 77 ms Safari: 204 ms. FF4 TM: 211 ms FF4 JM+TM: 248 ms
![]() |
Reporter | |
Comment 12•14 years ago
|
||
Yeah, sounds like we have headroom here and that this bug as reported is still there. ;)
Comment 13•14 years ago
|
||
Some progress in the last month, and to summarize: Chrome 8: 135 ms Safari 5: 300 ms Opera 10.63: 350 ms TM: 358 ms JM/TM/prof: 390 ms With fillRect/fillStyle commented out: Chrome 8: 71 ms TM: 185 ms JM/TM/prof: 210 ms Safari 5: 211 ms JM: 213 ms Opera 10.63: 312 ms So, the JS part is still slower than Chrome but faster than Opera and getting faster than Safari. fillRect/fillStyle is responsible for going from 2th place to 4th (last) place.
Comment 14•14 years ago
|
||
On windows this is 280 ms -with- fillRect/fillStyle, and 30 ms without in Minefield. Chromium is 120 ms with fillRect and 10 ms without. I'll check out what is making the graphics part of this so slow on windows.
Comment 15•14 years ago
|
||
(In reply to comment #14) > I'll check out what is making the graphics part of this so slow on windows. Thanks! Also see bug 601176 for the fillRect issue.
OS: Mac OS X → Windows 7
![]() |
Reporter | |
Comment 16•14 years ago
|
||
Note that just commenting out the canvas stuff doesn't just eliminate graphics time; it also removes the actual code needed to make the calls through xpconnect, possibly changes the results of -p, etc. To do an apples-to-apples comparison, either you need to time the canvas stuff separately and subtract, or you need to replace the canvas stuff with equivalent (in terms of how the jseng treats them) but known-fast DOM method calls and property sets.
Comment 17•14 years ago
|
||
So, I've been looking at this test case and my profiles. A couple of things are easily noticable: We spend about 30% in setting the fillstyle, of which the majority is spent ... parsing the color string. Then we spend about 35% actually painting, where a lot of time is spent doing things like 'gfxContext::SetColor' or 'gfxContext::Rectangle' which are all just things that go 20 stacks deep in order to create all the right various cairo types. Less than 15% of our time is -actually- spent doing the FillRectangle call in Direct2D. Hence we are losing a -lot- of time in setup overhead. One thing that definitely doesn't seem to be taking a lot of time in the profile is JS. The amount of things that JS does is just insignificant to the amount of painting calls that are executed (and setting up all the cairo state for it).
![]() |
Reporter | |
Comment 18•14 years ago
|
||
Hmm. Can someone file a bug blocking this one on the fillstyle set issue? Ideally with a microbenchmark. That should be not too hard to make faster.
![]() |
Reporter | |
Comment 19•14 years ago
|
||
Er, nevermind. The "reduced testcase" attached here is pretty minimal.
Comment 20•14 years ago
|
||
(In reply to comment #19) > Er, nevermind. The "reduced testcase" attached here is pretty minimal. I wonder if we can cut out the fillrect and still get the style string parsed?
Comment 21•14 years ago
|
||
(In reply to comment #19) > Er, nevermind. The "reduced testcase" attached here is pretty minimal. Then this bug (not a metabug) is morphing into a gfx bug? /be
Comment 22•14 years ago
|
||
Comment on attachment 480036 [details]
fillStyle/fillRect test case
Renamed the test case to clarify that it's only about fillRect/fillStyle.
Attachment #480036 -
Attachment description: Reduced test case → fillStyle/fillRect test case
![]() |
Reporter | |
Comment 23•14 years ago
|
||
No; the attached testcase just had nothing to do with this bug. This bug is specifically about JM being slower than TM and others on the relevant testcase, not about the fact that TM is slower than others per se. If that bug is fixed, fine. This should be marked fixed. But comment 13 doesn't sound like that's quite the case, and we definitely have work to do to catch up to V8 even for the JS only part. Maybe that should happen in a separate bug, though. I do think we need some additional gfx or DOM bugs here, and perhaps create a tracking bug for this testcase...
Comment 24•13 years ago
|
||
With JM+TI, I get 204-209ms vs. 137-151ms for Chrome on Win7 w/ D2D enabled.
Comment 25•11 years ago
|
||
In the light of comment 23, this is invalid. I don't, however, know if any gfx or DOM bugs have been filed. FWIW, Chromium is at ~60ms vs. our ~102ms, right now. @bz: please reopen if you think more should be done here.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
![]() |
Reporter | |
Comment 26•11 years ago
|
||
> FWIW, Chromium is at ~60ms vs. our ~102ms, right now.
For the JS-only testcase or the one involving gfx calls?
Flags: needinfo?(tschneidereit)
Comment 27•11 years ago
|
||
The one involving gfx calls. I didn't look into the other one as this bug's history says the js part is fixed. It might have regressed, but testing every bug-that-should've-been-closed-long-ago for regressions doesn't make sense to me. ;)
Flags: needinfo?(tschneidereit)
![]() |
Reporter | |
Comment 28•11 years ago
|
||
> as this bug's history says the js part is fixed. Where, exactly? The last comment I see with numbers for the JS part is comment 13, which shows that we had gotten it to almost TM perf, and were 3x slower than V8, right?
Flags: needinfo?(tschneidereit)
Comment 29•11 years ago
|
||
FWIW I get the following progression of times on the linked page: Firefox Nightly: 97ms, 68ms, 73ms, 58ms, 60ms Chromium Nightly: 49ms, 50ms, 46ms, 53ms, 46ms And on the fillStyle/fillRect test case: Firefox Nightly: 19-20ms Chromium Nightly: 8-9ms So Firefox seems to have more of a warm-up period on the A* benchmark. After warmup it's still about 20% slower then Chromium. The ratio on the attached test case is much improved compared to comment 5, at least on my machine, but Chromium is still twice as fast.
Comment 30•11 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #28) > > as this bug's history says the js part is fixed. > > Where, exactly? The last comment I see with numbers for the JS part is > comment 13, which shows that we had gotten it to almost TM perf, and were 3x > slower than V8, right? So I *might* have read too much into the comparison with TM, sorry about that. Emanuel, thanks for those updated numbers!
Status: RESOLVED → REOPENED
Flags: needinfo?(tschneidereit)
OS: Windows 7 → All
Hardware: x86 → All
Resolution: INVALID → ---
Summary: JM: Slower performance than tm and competition on "new" JS A* benchmark → IM: Performance on "new" JS A* benchmark somwhat volatile and between 30% and 100% slower than v8
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
![]() |
||
Comment 31•9 years ago
|
||
Setting the heuristic to 0 on the website benchmark, I get 112ms for Firefox 43 and 164ms for Chrome 47.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•