There was a discussion on IRC recently about PNG vs. SVG output files. The
questions we had revolved around how "hard" it is to generate each format,
and also decode it as well. Lacking any hard numbers, I decided to make up
my own. :)
All tests were run on my laptop, a Pentium-M 1.6GHz box (cpu at
full-throttle), using rrdtool 1.2.23. The .rrd files came from an recent
Ganglia build from the SVN trunk. I copied an .rrd file into a ramdisk, and
ran a shell script to benchmark creating and "rendering" PNG and SVG files.
Creating the files was pretty simple: I just ran these two command a
thousand times (<grin>):
rrdtool graph /dev/null -a PNG DEF:load=$FILE:sum:AVERAGE
LINE1:load#ff0000:load
rrdtool graph /dev/null -a SVG DEF:load=$FILE:sum:AVERAGE
LINE1:load#ff0000:load
Before the loops, I ran 'dd' on the various input files to make sure they
were cached, although since the tests were run on a RAM disk, that shouldn't
matter much.
Generating 1,000 PNG files took:
real 28.57
user 21.89
sys 2.29
Generating 1,000 SVG files took much less time:
real 4.18
user 2.34
sys 1.03
This makes quite a bit of sense. Since SVG is just XML, all that really
needs to be done is wrap some XML stuff around the datapoints. Making the
PNG actually requires requires plotting points, and generating the bitmap.
Once we make the image files, we need to decode them. This is a bit harder,
and I couldn't think of a way to easily benchmark Firefox's SVG rendering
code. Instead, I used the 'convert' program from ImageMagick to convert the
output SVG and PPM files into the next closest thing: a PPM file. I
realize that this does not tell us anything about browser rending, and might
be completely useless. I hope, however, that we can get a rough idea of how
"hard" it is for a browser to render an SVG file relative to a PNM file.
Thus, I ran these commands 1,000 times each:
convert -depth 8 +antialias test.png ppm:- > /dev/null
convert -depth 8 +antialias test.svg ppm:- > /dev/null
The input files are the files created by rrdtool, with no other
manipulation. It is interesting to note that the image dimensions on the
.svg file are slightly smaller than the png:
test.png PNG 481x168 481x168+0+0 DirectClass 8-bit 15.2695kb
test.svg SVG 470x168 470x168+0+0 DirectClass 16-bit 6.28906kb
Also note that the .svg file is less than half the size of the .png.
The numbers
"Decoding" PNG files:
real 47.50
user 37.94
sys 3.79
"Decoding" SVG files:
real 149.44
user 119.52
sys 7.34
So it looks like generating SVG files is clearly faster than PNG files, by
about a factor of 10 (User CPU time). On the other hand, "decoding" the
files with the 'convert' program was clearly slower at SVG files.
The source RRD file and script ar available if anyone wants to play with
them on their own.
Comments?
--
Jesse Becker
GPG Fingerprint -- BD00 7AA4 4483 AFCC 82D0 2720 0083 0931 9A2B 06A2
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
