Timed performance for various browsers for graphical standards
(SVG benchmarks)

(September 2008)

Seconds to build and render 50 objects iteratively (median of three trials)
Chrome/Win Firefox/Win IE/ASV Opera/MacB Opera/Win Saf/Ipod Saf/MacB Saf/Win
path .55±.04 1.65±.2 .84±.09 1.23±.15 1.05±.06 10.4±1.5 .55±.01 .78±.01
ellipse .51±.04 .58±.02 .79±.09 .57±.02 .84±.04 6.7±2.1 .54±.01 .79±.05
User agent versions:

Impressions: i-phone support is about the same as in Safari for Mac/Win in terms of what works and what
doesn't. Ditto for Chrome, but, there are some bugs (it is a beta after all -- though I couldn't figure out
where to report them). I-pod SVG is slow.

Methodologies: As presented at SVGOpen 2007,
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2007/SVGOpen2007.htm ,  I timed some things
for various browsers, using the SVG DOM chamber
To make the comparisons easy to perform across a multitude of browsers, I just looked at two classes of
objects: paths (big random triangles) and circles (little circles at random locations). These two
objects were representative of the range of browser differences observed in earlier testing and showed
strong browser-by-objecttype intereactions in the previous work. The DOM insertion mode was iterative
rather than concurrent (meaning it was controlled by a JavaScript timing loop to allow rendering to
finish as discussed in the paper
http://www.svgopen.org/2007/papers/BrowserPerformanceMeasures/index.html )

Note: no significance testing was done -- results report median of three trials (a statistic not known for
its reliability). However, were statistical testing to be done on a greater number of trials, I will bet a
beer that both main effects and the two-way interaction (browser by content type) would be significant --
i.e., wearing my hat as a former stat prof: the results are pretty robust. The reason for the high
variability with large triangles is that different amounts of overlap between triangles occurs and the
way that certain browsers (notably FF) paint the screen will be expected to vary as a function of that
randomness in the actual Monte Carlo analysis.

Other impressions: Chrome is quite fast, rivaling Safari in its "native environment" (MacBook). I-pod
implementation is slow -- as in by integer multiples. Both have a long ways to go in terms of catching up with
Opera in the extent of the spec actually handled to date.