Closed Bug 526380 Opened 11 years ago Closed 3 years ago
Polyfield example is much faster in webkit
The linked polyfield example is currently much faster in webkit.
The poor FF perf doing the twitter rounds. :-/ e.g. http://twitter.com/UnitZeroOne/status/5400573136
Are you going to analyze this?
General outline, fwiw: 30% appending nodes to the DOM, almost all of it under nsSVGUtils::UpdateGraphic (which seems to be called via nsFrame::Init according to shark(???) and nsSVGDisplayContainerFrame::InsertFrames). 15% removing from the DOM, almost all under Invalidate() call nsFrameManager::RemoveFrame makes and the nsSVGDisplayContainerFrame::RemoveFrame call into ... nsSVGUtils::InvalidateCoveredRegion. ~15-20% running JS (3% on trace; 2% entering and leaving trace; you might want to file some bugs on the non-tracing bits). 7% setting attributes on DOM nodes; at least half of this is nsSVGDataParser::Parse called from nsSVGPathElement::BeforeSetAttr. This is mostly spending time under MatchSubPath. About 10% painting. Huge amounts of memory traffic: 5-6% of the time is mmap and munmap.
I'm seeing 5-6MB worth of nsSVGElement::UpdateContentStyleRule allocations and 12-13MB worth of setting attrs to strings. Also 8 megs allocated from js_ValueToCharBuffer calling js_NumberValueToCharBuffer. Might be worth looking into why that's happening. 4MB worth of NS_NewSVGPathElement. Several MB of rects tossed into our invalidation regions, looks like. -18MB from GC (actually freed some memory!). If shark's not trying to me, about 2.5GB (over 30 seconds) of memory traffic from CGReleaseRegion and CGUnionRegionWithRect reallocing all over; nets out to 0, but might cost at the time... That's from all the invalidation we're doing.
URL is dead. :(
In the two examples from comment 6 where we're lagging behind other implementations ('svg' and 'svg_aliased') we are spending over 75% of the time in gfxContext::Fill(), suggesting that we're just slow to draw. (OS X 10.8.) The number of SVG <path> elements that are being removed and regenerated each "frame" is 500, so it's not a huge number, although they can fill the entire content area.
Whiteboard: [in-the-wild] → [in-the-wild][perf:painting]
We're now also using Skia on OS X. We should retest this.
Depends on: skia-osx
Enough has changed that it's worth closing this bug and opening another. I opened bug 1348607.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.