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.
We're now also using Skia on OS X. We should retest this.
Enough has changed that it's worth closing this bug and opening another. I opened bug 1348607.