How many SVGs before performance issues?

[Richard Smith]

Looking at the example using Google Maps, I see each point is rendered
in its own SVG. I guess that this will be more resource intensive than
rendering a similar quantity of child circles within one SVG. My
dataset includes about 60,000 points which I will want to draw on a
map, and possibly will want to draw arcs between points too.

Will d3 suffer any performance problems with a dataset this large?
i.e. with ~60,000+ SVGs?

If not, is there a ballpark theoretical upper limit to the number of
separate SVG elements which will draw in a modern browser on an
average PC without performance issues? How about with one SVG but many
child elements?

If so, is there some way I can mitigate the problem?

[Jon Frost]

Theoretically, I think the upper-limit is in the hundreds of thousands of elements.  For millions, consider using Canvas.  Using a single SVG parent will require significantly less code.

It really varies depending on the type of application being developed.  Often once the script that generates the SVG has been loaded the performance is better, so in many cases a preloader can be used initially.  Since D3 is so easy to use, I would recommend whipping together some tests to see what is acceptable for you app - for the browsers you want to support.

I often use this performance test tool to test the capabilities of browsers as it allows for quickly testing several key things - http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2007/SVGChamber98.html
More info here - http://www.svgopen.org/2007/papers/BrowserPerformanceMeasures/index.html#S3

     Jon

[Nelson Minar]

On Wed, Jul 13, 2011 at 4:41 AM, Richard Smith <richard...@gmail.com> wrote:

Will d3 suffer any performance problems with a dataset this large? i.e. with ~60,000+ SVGs?

I've found it really difficult to predict SVG performance. On windhistory.com I found rendering 2500 circles (in a single SVG tag) was no big deal. Rendering 2500 diagrams made of 12 paths, though, was sort of acceptable on some browsers and really too slow on others. Actually a single render wasn't bad. But any sort of interaction, even simple panning, was awful. (Ie: about 1 update a second).

Be aware that iOS SVG rendering is particularly slow. If you care about how it works on an iPad, that's your lowest common denominator.

[Richard Smith]

Thanks for the suggestion - canvas might be the best bet when I start
using very large datasets. I'm working with SVG for now because that's
what all the examples use and I'm still very much learning. Once I've
thoroughly got to grips with d3, I'll start branching out from SVG.

Am I right in thinking that a preloader won't work when overlaying the
shapes on Google Maps because they are all refreshed whenever the map
is zoomed or moved?

> More info here -http://www.svgopen.org/2007/papers/BrowserPerformanceMeasures/index.h...
>
>      Jon

[Richard Smith]

Wow, windhistory.com is great! It has a lot of similarity to what I'm
planning to do, looks very clean and the visualisation is intuitive.
I'm only planning to use plain circle elements with the full dataset -
perhaps I should limit visualisation to a subset of the data for now.
I'll try it with the full set and report back with results.

On Jul 13, 2:22 pm, Nelson Minar <nel...@monkey.org> wrote:

[Nelson Minar]

On Wed, Jul 13, 2011 at 6:42 AM, Richard Smith <richard...@gmail.com> wrote:

Wow, windhistory.com is great!

Thanks! I wrote some implementation notes here: http://www.somebits.com/weblog/tech/wind-history-implementation.html

A key piece of what makes this work is a tiler so that Polymaps only inserts the SVG generated by D3 for stuff on screen. Mike wrote that for me, not sure it's made its way into D3. If not you can find a copy and demo at http://bl.ocks.org/900050

[Saurabh Jain]

Hi,

I really liked the way wind speed data is rendered in the circle and the way the data changes per month. It will be really great if some more info can be shared on how this was implemented. Is it possible to share some code snippet also?

Thanks

Saurabh

[Nick Diakopoulos]

A few months back I wrote a little test sketch to look at rendering performance of different network visualization options. I found D3 rendering to SVG was only good for a few thousand nodes and edges when animated. http://www.nickdiakopoulos.com/2012/05/14/visualization-performance-in-the-browser

Nick

[manifesto]

I have a visualization with an area chart (svg:path). Static rendering occurs quickly. However, transitions get chunky and fail (i.e. don't animate) around ~2000 points.

[Stephen Bannasch]

At 6:03 AM -0700 8/9/12, Nick Diakopoulos wrote:
>A few months back I wrote a little test sketch to look at rendering performance of different network visualization options. I found D3 rendering to SVG was only good for a few thousand nodes and edges when animated. http://www.nickdiakopoulos.com/2012/05/14/visualization-performance-in-the-browser

I found the same results with two benchmarks I made almost a year ago.

Benchmarks show how long it takes to draw lines from 250 to 5000 line segment in Canvas and SVG:

Canvas: http://bl.ocks.org/1297383
SVG: http://bl.ocks.org/1296930

Time to plot 500 line segments (ms):

canvas svg
Chrome 20 46 811
Safari 5.1.7 49 932
Firefox 14.0.1 6543 80

There is something VERY strange going on in Firefox v14 -- the SVG test is MUCH faster than in Chrome and Safari and the Canvastest is absurdly slow and the line isn't actually rendered!

Must be doing something wrong -- but teh program is very simple -- I don't think I saw this problem last year ???

[Marc Fawzi]

The Firefox has been metaphorically castrated. Google hired away their best people. They have been making some low quality decisions on the product side. Sad.

Sent from my iPhone

[Stephen Bannasch]

At 6:16 PM -0700 8/9/12, Stephen Bannasch wrote:
>Benchmarks show how long it takes to draw lines from 250 to 5000 line segment in Canvas and SVG:
>
>Canvas: http://bl.ocks.org/1297383
>SVG: http://bl.ocks.org/1296930
>
>Time to plot 500 line segments (ms):
>
> canvas svg
>Chrome 20 46 811
>Safari 5.1.7 49 932
>Firefox 14.0.1 6543 80

correct these summary results are for 5000 line segments -- NOT 500!

[Ger Hobbelt]

On Fri, Aug 10, 2012 at 3:16 AM, Stephen Bannasch <stephen....@deanbrook.org> wrote:
>
> I found the same results with two benchmarks I made almost a year ago.
>

> Benchmarks show how long it takes to draw lines from 250 to 5000 line segment in Canvas and SVG:
>
> Canvas: http://bl.ocks.org/1297383
> SVG:    http://bl.ocks.org/1296930
>
> Time to plot 500 line segments (ms):
>
>                 canvas     svg
> Chrome 20          46      811
> Safari 5.1.7       49      932
> Firefox 14.0.1   6543       80
>

> There is something VERY strange going on in Firefox v14 -- the SVG test is MUCH faster than in Chrome and Safari and the Canvastest is absurdly slow and the line isn't actually rendered!
>
> Must be doing something wrong -- but teh program is very simple -- I don't think I saw this problem last year ???

Your canvas test uses a non-default composition mode (destination-atop) which on several browsers ends up showing one or very few line segments. The default -- which would produce output like the SVG test, incidentally -- is source-over.  Interesting is that Safari, Chrome, Safari, Opera and IE9 exhibit some quite different behaviour for composition modes other than source-over.


Showdown at the OK Coral

First there's Opera.
Run your Canvas test in latest Opera and it is... the epitome of 'sluggish'; in fact, it is more than 400 TIMES SLOWER than the SVG render -- which is blazingly fast compared to other browsers, but that's another item:
Opera 12: Canvas => 5000 pcs @ 17848 msecs, where last 250 pcs @ 878 msecs
Opera 12: SVG => 5000 @ 26, last 250 @ 1
(*nobody* beats Opera's numbers for SVG, BTW, except there's that one browser manufacturer and Redmond resident...)

Chrome 20: Canvas => 5000 @ 31, last 250 @ 2
Chrome 20, SVG => 5000 @ 2303, last 250 @ 226
Note the 100x speed difference with SVG/Opera! Visually, you can see Chrome updating, Opera is just 'bang!' and done, so it's not a measurement error.

The last250 times are relevant here as they do not include any possible differences in the implementation of the 'animation timers' in the various browsers. Opera keeps near constant time O(1) in SVG while the other browsers all exhibit O(n^2) behaviour for SVG. Again, the Redmond native excluded, here, but you'll see that happening when it arrives further below.

Firefox 14, Canvas => 5000 @ 602, last 250 @ 31
Firefox 14, SVG => 5000 @ 90732, last 250 @ 10191

This looks just plain horrible for SVG. (It also nicely explains why I had such headaches getting a site to perform with FF a while back.) 

Keep in mind that these numbers for Canvas are for the original 'destination-atop' gist http://bl.ocks.org/1297383 ; when you change that to 'source-over', as we will at the end, the time difference factor jumps by about another decade and some things change dramatically. Firefox SVG isn't O(n) but probably O(n^2) as 

  Firefox 14, SVG => 500 @ 97, last 250 @ 5
is not a factor of 10 compared to the 5000 pcs render, but rather a factor of 100 --> O(n^2) SVG performance. Ouch.

In case anyone believes 'the best' FF engineers were bought off by Google/Chrome, think again, because here's Chrome for comparison:
  Chrome 20, SVG => 500 @ 36, last 250 @ 24
so Chrome is also somewhere close to O(n^2), given their 5000 pcs number of 2303. Yes, they're probably somewhere between O(n log n) and O(n^2) performance -- golly! -- but it still is _way_ different from Opera 12: 500 @ 4, last 250 @  2 while 5000 @ 26, meaning we're looking at something between O(n) and O(1) instead for Opera; (O(n) would imply a factor of 10 in time between the 500 and the 5000 sample, while actual measurement produces 26 instead of expected O(n) = 40). Now the boys and gals at Opera sure show smarts, here.
Anyway, if anybody has been buying off anyone else's engineers, it's got to be Opera. ;-) Or maybe those Redmontanians, who knows... pecunia non olet, eh.
Alas, so much for the Google/Chrome vs. FF conspiracy theory. *Busted*

Okay, Safari/Win, another Webkitty like Chrome, sort of, but...

Safari 5/Win, Canvas => 5000 @ 95, last 250 @ 4
Safari 5/Win, SVG => 5000 @ 1568, last 250 @ 151
while SVG => 500 @ 32, last250 @ 12
so something of an O(n log n) here? O(n^2) would get us 3200 instead of 1568. There's a factor of 2 in there: it's either overhead being optimized on the fly or something that's leaning towards O(n log n) underneath.
Recall that Chrome did take 2303 msecs for the same and a 5000/500 ratio of 2303/36, so there's that same O(n^2) estimate vs reality factor 2 (3600:2302) again. Indeed looks like another Webkitty here.

For now, given that 2x factor, my bet is on O(n^2) for both, with some optimizations elsewhere which show up when you scale the buggers.

Incidentally, Safari is the one where the original Canvas 'destination-atop' gist rendered just like the SVG one; given https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.html we can conclude that Safari is offering incomplete support in the canvas composition mode department. Stay tuned for some surprises with the others...

Meanwhile, there's IE9, in both 32-bit and 64-bit renditions:

IE9/32-bit, Canvas => 5000 @ 1011, last 250 @ 51
IE9/32, SVG => 5000 @ 20, last 250 @ 1
Whoa, Nelly!
SVG => 500 @ 2, last 250 @ 1
beats up-to-now-fastest kid on the block Opera and leaves all the other browser lovers eating Microsoft dust. Watch my tail lights, baby! See the red-shift, hon'?

An O(n) animal in SVG, which is very nice work!

IE9/64, Canvas => 5000 @ 964, last 250 @ 47
IE9/64, SVG => 5000 @ 96, last 250 @ 4
Both IE9/32 and IE9/64 exhibit O(n) behaviour (IE9/64, Canvas => 500 @ 98, last 250 @ 47) for canvas for 'destination-atop', while they exhibit something between O(1) and O(n) for SVG (IE9/64, SVG => 500 @ 33, last 250 @ 4)

Keep in mind that 'n' for canvas is pixels, not line segments (nodes) like it would be for SVG.

Also keep in mind that this is canvas in destination-atop composition mode.


Oh, and incidentally, bl.ocks.org code b0rks like the best of them in IE9: the iframe gets rendered (praise Allah) but nothing about the accompanying source code display nor any of the markdown-ed text for ye skunners.



Conclusion?

The O(...) expression in observed behaviour is bloody important when you're going to scale this up, i.e. intend to use SVG or Canvas with large numbers of graphic elements (here, only lines have been tested, but it gives some surprising results already)

The browsers which are expected to scale nicely in SVG are the ones which have algorithms underneath which exhibit O(n) cost or better, so that would be Opera and IE9.
Anything that's O(n^2) or close to that will have your old CS math professors frothing at the mouth. The slow buggers at scale are: Chrome, Firefox, Safari, as each is certainly performing worse than O(n log n) and only Safari and Chrome are marginally better than raw unadulterated O(n^2).


Hold it! What about <Canvas>?

Right. Canvas. It's ... faster. Iff... ... ...
Theoretically it should _always_ be able to beat SVG at any scale because there's no node hierarchy to maintain/search and it's the same pixels it's got to push, but apparently some folks have a spot of trouble coping with certain composition modes, Opera in particular.

Have a look at this bugger:
http://bl.ocks.org/3331545
and notice the differences:

Firefox 14, Canvas =>
3250 @ 312 , last 250 @ 1, for: source-over
3500 @ 340 , last 250 @ 28, for: destination-atop

Chrome 20, Canvas =>
3250 @ 19 , last 250 @ 1, for: source-over
3500 @ 20 , last 250 @ 1, for: destination-atop

Safari 5/Win, Canvas =>
3250 @ 29 , last 250 @ 2, for: source-over
3500 @ 32 , last 250 @ 3, for: destination-atop

Opera 12, Canvas =>
3250 @ 6969 , last 250 @ 8, for: source-over
3500 @ 9818, , last 250 @ 2849, for: destination-atop

IE9/32, Canvas =>
3250 @ 453, last 250 @ 2, for: source-over
3500 @ 505, last 250 @ 52, for: destination-atop

IE9/64, Canvas =>
3250 @ 417, last 250 @ 3, for: source-over
3500 @ 465, last 250 @ 48, for: destination-atop

The numbers to watch here are the 'last 250' ones: these (and a few other numbers) tell us that Canvas is indeed matching the theoretical expectation of 'faster than SVG, always', only when you stick with the 'source-over' composition mode in any browser.

The surprising bit is the slowdown factor for the various browsers, which are thought provoking, particularly in the case of Opera, where they disappear right off into that elusive WTF County:

• Webkitties shrug about composition modes (but Safari and Chrome agree to disagree on the final render result nevertheless): they don't really care. composition mode isn't a speed factor to consider there, maybe it's 2x if you really want to push home a point about it, but that's already stretching it.
• FireFox, OTOH, hits the brakes as soon as you dare tread outside the 'source-over' composition realm: depending on where you look you observe at least an order of magnitude slowdown: 10..30, with the higher number when there's more opaque pixels to juggle. Not nice.
• IE9 lands in the same ballpark at about 20x slowdown for anything but 'source-over'.
• The big surprise is Opera, which hits us with a ~ 300x (yes, that's two significant zeroes right there, y'all! Hot dang!) slowdown, BUT this only happens if you dare use destination-atop, destination-in, copy, source-in or source-out composition modes. Apparently, someone over at Opera had it in for these, since any other mode is on par with the default 'source-over' mode.

Canvas, only in a rerun

To close this off, here are the SVG vs. Canvas numbers again, where canvas now has been done in 'source-over' mode to mimic the SVG behaviour. The corrected canvas benchmark can be found here: http://bl.ocks.org/3331937


Opera 12: Canvas => 5000 @ 103 , last 250 @ 8 (compare to 5000 @ 17848 previously!)
Opera 12: SVG => 5000 @ 26, last 250 @ 1

Chrome 20: Canvas => 5000 @ 25 , last 250 @ 3 (previously 5000 @ 31)
Chrome 20, SVG => 5000 @ 2303, last 250 @ 226

Firefox 14, Canvas => 5000 @ 35 , last 250 @ 2 (previously 5000 @ 602)
Firefox 14, SVG => 5000 @ 90732, last 250 @ 10191

Safari 5/Win, Canvas => 5000 @ 48 , last 250 @ 3 (previously 5000 @ 95 [*])
Safari 5/Win, SVG => 5000 @ 1568, last 250 @ 151

IE9/32-bit, Canvas => 5000 @ 50, last 250 @ 2 (previously 5000 @ 1011)
IE9/32, SVG => 5000 @ 20, last 250 @1

IE9/64, Canvas => 5000 @ 47, last 250 @ 3 (previously 5000 @ 964)
IE9/64, SVG => 5000 @ 96, last 250 @ 4

[*] when you run these tests yourself, you'll note that running them again can produce significant differences for the smaller numbers, up to a factor of 2: another run for Safari produced 84 instead of 48 msecs for 5000 line segments. Of course the differences for the bigger numbers are very much less, it's just the small ones which have this big a 'jitter' to them, obviously.

This is why performance measurement sites such as jsperf.com run tests multiple times and calculate avg and spread of the measured times to decide whether it's a good run or not, and what the reported number should be. I've been lazy in that I only ran the tests 2 or 3 times. The factors and O(...) expressions shown here remained near constant enough throughout for my tastes: Opera in 'destination-atop' mode didn't get any faster by running it again and again and again, for one.


And what about Stephen Bannasch's numbers?

Well, I can't explain the FF numbers Stephen's got, apart from the observed slowness, but FF over here still is faster at canvas in 'destination-atop' than when doing SVG. Maybe FF was of a different mind last year, when it was at a different build number, but it might be prudent to check the numbers here: my numbers originate from one box, so unless I fubarred the bunch, yours should at least match these by a close-to-constant factor when you rerun the tests on another machine, using the same browser versions.

I went and rechecked mine, but noticing your own blind spot hasn't ever been my forte, so the German adage applies, as ever: Vertrauen ist gut, Kontrolle ist besser. (And when you google that, the translation you'll dig up is off: Kontrolle isn't so much Control as it is Verification, i.e. 'Making sure/checking up on something'. English control is rather more like german Führung (yeah yeah, I know... glad you saw it too), so a good translation would keep the spirit of it, keep Frank Zappa in mind, hence end up as 'Trust is good, Scrutiny is better'. Your Central Scrutinizer would certainly agree, so why wouldn't you?)

The Final Verdict

If you want FAST at scale, you go for SVG on IE9 and Opera -- though canvas is close behind or on par -- while the other, better known 'non-M$ browsers' all suffer from a severe case of O(n^2) when running in SVG, where Firefox beats them all (Safari and Chrome) when it comes to 'animation'. It's just a wee bit of an exaggeration to state that for large graphs you don't need d3 transitions for animations but just let Firefox run and enjoy the drawing while it happens @ 90 seconds for 5000 line segments, which is ~ 45 times slower than the runner-up in the 'snails pace' competition: Chrome.

Pity the display doesn't update while JavaScript is running, as now Firefox makes SVG rendering look like Bill the Cat barfing a hairball.

That '45' right there might give you ideas, but when you look closer at the numbers you'll agree that both suffer from O(n^2) type behaviour, which makes that little '45' utterly insignificant when you scale up the complexity of your SVG renderings. For these buggers, the only way out for you as a user and graphics coder is using Canvas, which exhibits O(1) or O(n) behaviour for all browsers, but for an entirely different n: the number of pixels you're juggling, and with a noticeable different constant at that.
With Firefox, your fastest race will be run in Canvas, with the default 'source-over' composition mode. Luck has it the others are all pretty darn fast there, too.
Is there such a thing as a booby prize?


Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------

[Ian Johnson]

Ger, you are obviously a scientist...

This deserves it's own blog post, as well as visualizations to go with it. thankfully we are the d3 mailing list so that shouldn't be a problem.

I've kickstarted it with some of the numbers:

http://enjalot.com/tributary/3333867/

it would be nice if we had a more systematic way to collect this data, or at the very least share it. even if we just store it in a spreadsheet it will be much easier to make some more visualizations. (would be good to know something about the hardware too, i get about 2x your chrome performance on my mackbook air).

fantastiche werk :)

--
Ian Johnson

http://enja.org

[Stephen Bannasch]

At 6:03 PM +0200 8/12/12, Ger Hobbelt wrote:

On Fri, Aug 10, 2012 at 3:16 AM, Stephen Bannasch <stephen....@deanbrook.org> wrote:

> There is something VERY strange going on in Firefox v14 -- the SVG test is MUCH faster than inChrome and Safari and the Canvastest is absurdly slow and the line isn't actually rendered!

>
> Must be doing something wrong -- but teh program is very simple -- I don't think I saw this problem last year ???

Your canvas test uses a non-default composition mode (destination-atop) which on several browsers ends up showing one or very few line segments. The default -- which would produce output like the SVG test, incidentally-- is source-over.  Interesting is that Safari, Chrome, Safari, Opera and IE9 exhibit some quite different behaviour for composition modes other than source-over.

Thanks for that tip -- I can't remember right now why I used destination-atop.

I've changed: http://bl.ocks.org/1297383 to use source-over and it works well in Firefox 14.0.1 now!

And what about Stephen Bannasch's numbers?

Well, I can't explain the FF numbers Stephen's got, apart from the observed slowness, but FF over here still is faster at canvas in 'destination-atop' than when doing SVG. Maybe FF was of a different mind last year, when it was at a different build number, but it might be prudent to check the numbers here: my numbers originate from one box, so unless I fubarred the bunch, yours should at least match these by a close-to-constant factor when you rerun the tests on another machine, using the samebrowserversions.

I've put updated results here for multiple browsers testing on my 2010 MacBook Pro running both Mac OS X 10.6.8 AND Windows7:

https://docs.google.com/a/concord.org/spreadsheet/ccc?key=0AtvlFoSBUC5kdEZJNVFySG9wSHZka0NsOTZDSkt3Nnc#gid=0

This google spreadsheet is shared so others can add more data for other platforms if they want.

Firefox 14.0.1 is still much faster than Chrome or Safari running the SVG Path Benchmark on both  Mac OS X 10.6.8 AND Windows 7.

IE9 on Windows 7 and Opera on both Mac OS X 10.6.8 and Windows 7 are in an effective tie for fastest at running the SVG Path Benchmark (33ms).

Chrome 21 on Windows 7 is the fastest running the Canvas Path Benchmark (17ms).

Chrome and Safari are MUCH slower than the other platforms running the SVG Path Benchmark.

Separately -- in the browser-based computational physics engines we are working on (which combine computational AND visualization performance) Chrome has by far the highest computational performance.

This CFD simulation runs 10x faster in Chrome than Firefox.

Example: http://lab.dev.concord.org/examples/energy2d-gpu-model/energy2d-model.html#interactives/benard-cell100.json

browser       fps

-------------------

Chrome 21       23.3

Safari 5.1.7    14.0

IE9              7.0   ** Win7

Opera 12         5.8

FF 14            2.6

[Ger Hobbelt]

On Sun, Aug 12, 2012 at 9:21 PM, Ian Johnson <enj...@gmail.com> wrote:

Ger, you are obviously a scientist...

Nah, at best a wannabe. ;-)

All I've got going for me is a mindset of one and a love for systems modeling (and consequently algorithms and a bit of archeology).

This deserves it's own blog post, as well as visualizations to go with it. thankfully we are the d3 mailing list so that shouldn't be a problem.

I've kickstarted it with some of the numbers:

http://enjalot.com/tributary/3333867/

it would be nice if we had a more systematic way to collect this data, or at the very least share it. even if we just store it in a spreadsheet it will be much easier to make some more visualizations. (would be good to know something about the hardware too, i get about 2x your chrome performance on my mackbook air).

fantastiche werk :)

Thanks!

Didn't rig my own site yet for a blogging workflow yet (one of those 'todo when the time is there' things... I know what I want, but it's not readily available yet that way so I need to fiddle some and the blog systems that I tried in the past faded away in my mind/habits very quickly. But I digress.) 

Anyway, tests were run on a Win7/64 platform, AMD Phenom II X4 910e @ 2.6GHz, 16 GB RAM.

I see your FF vs. Chrome ends up 'flipped' compared to mine; current working assumption there is that apparently my FF plugins are crapping up FF no end when it comes to SVG; I'll need extra time to check a clean FF in a VM and then see which of the addons is sniggering in a dark corner. :-(

So you see, a /real/ scientist would've started with ironclad 'certified clean' browsers for testing all this, while 'quick draw McGuff' lazy ol' me just ran with what's on the main box (I do have test VMs with the various browsers but that's for 'real test' work and, my mistake, I thought I could get away without booting those for this one; your numbers vs. mine are a loud hint that was a wrong assumption/test shortcut to take.)

I had considered using jsperf.com for this, because it's got [almost] all what we need, except it doesn't show the most interesting thing, which is the graph that plots time vs. line segment count, i.e. a plot of the table produced by a benchmark test run. That table/plot (and for extra goodness added linear, n.log(n) and n-squared 'fitted' curves plus correlation analysis :-) ) will show how the various browsers 'scale': the curvature of that plot would identify the 'O expression' of the underlying renderer/browser implementation.

jsperf.com would only give me the 'end results' and I'd loose the O(...) analysis.

Dang. An 'augmented jsperf.com' would be lovely for this.

[Ger Hobbelt]

On Mon, Aug 13, 2012 at 2:57 AM, Stephen Bannasch <stephen....@deanbrook.org> wrote:

Thanks for that tip -- I can't remember right now why I used destination-atop.

You're welcome. Thanks for creating the benchmarks in the first place; they triggered me to do this and it helped me to discover some things which were a bit of a mystery up till today, for me at least.

 

https://docs.google.com/a/concord.org/spreadsheet/ccc?key=0AtvlFoSBUC5kdEZJNVFySG9wSHZka0NsOTZDSkt3Nnc#gid=0

This google spreadsheet is shared so others can add more data for other platforms if they want.

Great!

 

Firefox 14.0.1 is still much faster than Chrome or Safari running the SVG Path Benchmark on both  Mac OS X 10.6.8 AND Windows 7.

As I wrote just now: I'll need to go back and test this stuff with 'certified clean' browsers; I guess some addon in FF is deteriorating my results there. 

Separately -- in the browser-based computational physics engines we are working on (which combine computational AND visualization performance) Chrome has by far the highest computational performance.

Yep, same finding here: as long as you're only dependent on JavaScript performance per se (no SVG/canvas/DOM rendering stuff), V8 is the fastest bugger of them all - probably why Node.js picked that one as the core engine.

Thanks for reporting your numbers; I'll need to do some more testing and maybe a bit of thinking too.

Anyhow, way past bedtime, so g'night and signing off here.

[Elijah Meeks]

Wow, I had no idea performance would work out like that. I gave up IE9 for dead when I found out they hadn't implemented ForeignObject, and I thought Chrome/Safari were greased lightning for SVGs. I'm working on a geographic visualization and I had to split the 6000 point dataset into five pieces because of performance issues from simply transitioning the colors of 6000 circles. I'm sure there are performance tuning issues, as well, but while I was willing to lose IE9 (and, apparently, don't need to as long as I forgo ForeignObject) I can't demand that everyone open a site in IE9 or Opera.

Thanks for doing this--I'd love to see this written up fully somewhere.

[Stephen Bannasch]

At 7:25 PM -0700 8/12/12, Elijah Meeks wrote:
>Wow, I had no idea performance would work out like that. I gave up IE9 for dead when I found out they hadn't implemented ForeignObject, and I thought Chrome/Safari were greased lightning for SVGs.

The results from my Canvas/SVG Path benchmark are ONLY comparing the performance for drawing a 5000 segment line. This was dataI wanted to know when I made a D3 grapher that needed to plot data VERY quickly.

I wouldn't be surprised to see similar SVG performance issues in WebKit-based browsers (Chrome, Safari) but I do not have any benchmarks for this.

[Stephen Bannasch]

I've added SVG and Canvas Path results for a Motorola Xoom Android 4.1.1, and an iPad 2 and iPad 3 running iOS 5.1.1 to the
benchmark results in this table:

https://docs.google.com/a/concord.org/spreadsheet/ccc?key=0AtvlFoSBUC5kdEZJNVFySG9wSHZka0NsOTZDSkt3Nnc#gid=0

Firefox Beta v15.0 is faster on the Xoom Android 4.1.1 tablet than Chrome or Safari in Windows 7 or Mac OS X 10.6.8!

It seems all of the WebKit-based browsers have a severe SVG performance problem drawing lines with large numbers of segments.

[Kai Chang]

Added some benchmarks for Ubuntu 12.04 Chromium and Firefox.

I started factoring a similar pattern into a reusable component "Render Queue", which I mentioned in an earlier thread today.

http://bl.ocks.org/d/3341641/

After looking at Stephen's benchmarks this afternoon, it's an almost identical mechanic. I must have incorporated it into parallel coordinates after looking at this code many months ago.

Thanks guys.

[VJ]

Still learning D3, and just getting good at understanding SVG rendering for line charts. Now looking at performance of 5000+ points on a line chart.

Hoping I do not need to switch to canvas, but I will if needed.

I just wanted to update this thread since now on chrome v 25.x SVG numbers seem to be much better, than v20-23. Hoping ipad and iphone will get better too.

[VJ]

Anyone using D3 specifically on iPad or iPhone?