[
Lists Home |
Date Index |
Thread Index
]
Danny Ayers writes:
> fyi: Scalable Vector Graphics (SVG) [1] allows for the use of the
> familiar gzip compression scheme, achieving worthwhile ratios. The
> Adobe SVG browser plugin supports this, and all in all it seems a
> successful approach.
zlib makes it trivially easy to support something like that
cross-platform -- we make extensive use of it in FlightGear
(Linux/FreeBSD/Windows/Irix/Solaris/MacOS/etc. etc.) for non-binary
input files.
If the input data is very, very randomized, then binary input formats
tend to be smaller than compressed XML, but not by as much as you
might expect. Consider a file containing 10,000 pairs of
pseudo-random integers. In a binary format using 4 bytes for each
integer, the file would require 80,000 bytes. I generated the pairs
in an XML format like this:
<value>
<component-a>448773211</component-a>
<component-b>539257706</component-b>
</value>
As you might expect, the resulting XML file was very large (13 times
the size of the binary file):
-rw-r--r-- 1 david david 1039309 Nov 18 12:46 foo.xml
Given that the integers are psuedo-random, and thus, lacking in
repetitive patterns, you wouldn't expect compressors to do a good job
-- they can factor out the tags, but not the numbers. However, plain
old gzip (-9) did pretty well, all considered:
-rw-r--r-- 1 david david 127976 Nov 18 12:46 foo.xml.gz
That's only 1.6 times the size of the binary file. Of course, bzip
(-9) did even better:
-rw-r--r-- 1 david david 91608 Nov 18 12:46 foo.xml.bz2
That's down to 1.2 times the size of the binary file.
So, the worst case isn't that bad, and in most real-life cases I've
seen, where the data has a lot more repetition, the compressed text
wins.
All the best,
David
--
David Megginson, david@megginson.com, http://www.megginson.com/
|
