Closed Bug 841931 Opened 12 years ago Closed 8 years ago

Poor performance in d3.js demo

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Version:
21 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: wraithan, Unassigned)

References

(
URL
)

Details

(Keywords: perf, testcase, Whiteboard: [Snappy] [in-the-wild] [external-report])

d3.js is a graphics library people use for making interesting graphs and such. This demo runs pretty sluggishly in Firefox. Taras asserted that it is not JS and told me to file a bug here. This is the demo in question: http://exposedata.com/parallel/ The poor performance happens when you mouse over the rows in the table.
http://people.mozilla.com/~bgirard/cleopatra/#report=3cd1ff64d158322305f2f25cc868f877ccaa7134 saw some displaylist stuff in the profile + svg
Whiteboard: [Snappy]
I have trouble figuring out how to use cleopatra, but if I'm understanding it correctly it looks like it's mostly SVG path drawing and hit testing.
It looks like entirely (well, 95%+) SVG path drawing to me in Instruments.
Component: Layout → SVG
Keywords: perf, testcase
Yeah, over 80% of the time spent under gfxContext::Stroke(). This page just contains a ton of sibling paths, so I'm not sure there's much we can do other than "make painting faster". (That is, we're not over-invalidating or reflowing unnecessarily or the like.)
FWIW Chrome Canary is laggy too, but for me still about 5x faster than latest Nightly + some soon to land perf patches that I have.
(In reply to Jonathan Watt [:jwatt] from comment #4) > Yeah, over 80% of the time spent under gfxContext::Stroke() Actually there's a second call stack that I missed calling gfxContext::Stroke(), so make that more like 94% of the time. And more specifically that time is spent under _moz_cairo_stroke_preserve.
Bas tells me that cairo is particularly slow at stroking. Implementing Quartz content on Mac will likely help a lot here.
Depends on: 836130, 715722
I turned on quartzgl locally and did not see much of an improvement. Time is being spent in aa_render in software which are not the quartz sse2 fast path.
No longer depends on: 836130
If you're looking for more examples of this library being slow, bl.ocks.org is a site full of d3 demo code. Pretty much everything on that site is much slower/more resource intensive in FF vs Chrome. Here's one in particular that causes FF to slowly grind to a halt while Chrome hums along w/o any problems: http://bl.ocks.org/mbostock/1021953
Whiteboard: [Snappy] → [Snappy] [in-the-wild] [external-report]
Another example of performance being poor is http://map.ipviking.com/ This works smoothly on Chrome. What forced me to put this comment is a comment on the website that said "Too Slow? Try chrome"
Firefox now seems to have the same performance as Chrome on the original site that this bug was filed for. The links given in comment 9 and comment 10 (which should be separate bugs next time please) also seem no slower.
On my Windows machine the switch from D2D1 to D2D1.1 (bug 902952) has made us at least 5x more responsive, and what feels like roughly 2x more responsive than Chrome.
Depends on: 902952
The original link does not work anymore, the link in comment 10 is also expired. The examples from comment 9 work fine on Windows 7, but the headers say this is an OS X issue. Is it still an issue? If it is, shouldn't the link be updated? And how about WinXP, which does not support D2D?
The link in comment 9 is still slower for me in FF (49.0b7) than in Chrome (52.0.2743.116) on OSX (10.11.4). In FF, after about 5 minutes on that page, the browser gets very stuttery and beachballs w/ CPU pegged above 100%, while in Chrome after the same amount of time everything is smooth and CPU is at ~80%.
(In reply to Jason Fager from comment #14) > The link in comment 9 is still slower for me in FF (49.0b7) than in Chrome > (52.0.2743.116) on OSX (10.11.4). In FF, after about 5 minutes on that > page, the browser gets very stuttery and beachballs w/ CPU pegged above > 100%, while in Chrome after the same amount of time everything is smooth and > CPU is at ~80%. Please check if you still see this issue and open a new bug report if you do. Bug reports get very messy and hard to process when they start morphing from one issue to another, to another.
As per comment 11 and comment 12 the original issue was fixed, so marking this bug report as fixed.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
God I love reporting bugs to Mozilla. This issue was for d3.js being slow, so I added another example, how is that "morphing from one issue to another, to another"? I guarantee if I had opened it as a separate issue four years ago someone would have given me **** for not searching open bugs and spamming the tracker.
I'm not trying to give you ****, complaining that you should know better, or anything like that. From your perspective "D3.js is slow" and lumping all issues anyone sees with D3 together may make sense. I understand that. At the same time if that causes problems for devs trying to fix bugs it's worth letting bug reporters know so they can help reduce the number of times it happens in future. Regarding D3, the reason it causes problems to lump different examples together in a bug is because D3 is simply a library that changes elements, attributes and properties, of which there are many. The underlying cause of D3 slowness on one testcase is often completely different to the cause for another. For example, one testcase might be animating the 'transform' attribute, while another might be animating path vertices. If I end up implementing some sort of caching to speed up transform animation (possibly many patches, and dozens of review comments) to fix one reported example, I don't want to have a parallel or subsequent conversation in the same bug on an unrelated issue such as speeding up stroking of a path's vertices. Conversations can then get messy, overlap, and devs/reviewers waste time reading and processing comments that may have already been fixed or be unrelated to what they're working on at a given point in time. (In reply to Jason Fager from comment #17) > I guarantee if I had opened it as a separate issue four years > ago someone would have given me **** for not searching open bugs and > spamming the tracker. I would certainly hope not! Not only are D3.js issues likely to be unrelated, but http://exposedata.com/parallel/ http://bl.ocks.org/mbostock/1021953 http://map.ipviking.com/ are all on completely different domains.
So simply ask for a separate ticket. What's the value in snarking about "morphing from one issue to another, to another" when from a submitter's perspective they're very reasonably the same high-level issue of d3 perf? Anyways: https://bugzilla.mozilla.org/show_bug.cgi?id=1348837
You're reading snark into my comment where none was intended - one of the hazards of purely written communication I guess. Along with the request to open a new bug I was simply trying to explain why that was desirable. (In reply to Jason Fager from comment #19) > Anyways: https://bugzilla.mozilla.org/show_bug.cgi?id=1348837 Thank you, much appreciated.
> I guarantee if I had opened it as a separate issue four years ago someone would have given > me **** for not searching open bugs and spamming the tracker. Jason, if this ever happens to you for a performance bug, please feel free to mail me and I will explain how performance bugs work to this someone. :) In general, unless there is an actual profile showing the problem is exactly the same, or the actual page being reported on is identical, separate performance bugs should remain separate, because they almost certainly indicate separate problems. I know dealing with the different perspectives on "this page is slow" involved here is frustrating; thank you for reporting these issues!
You need to log in before you can comment on or make changes to this bug.