[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML / HTML Transport size

• To: xml-dev@l...
• Subject: RE: XML / HTML Transport size
• From: David Megginson <david@m...>
• Date: Mon, 18 Nov 2002 13:00:48 -0500
• In-reply-to: <EBEPLGMHCDOJJJPCFHEFMEPNIHAA.danny666@v...>
• References: <200211181217.HAA13976@m...><EBEPLGMHCDOJJJPCFHEFMEPNIHAA.danny666@v...>

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@m..., http://www.megginson.com/

• References:
  • Re: XML / HTML Transport size
    • From: John Cowan <jcowan@r...>
  • RE: XML / HTML Transport size
    • From: "Danny Ayers" <danny666@v...>

• Prev by Date: RE: dtds, schemas, xhtml, and multimedia technologies
• Next by Date: Re: RDF for unstructured databases, RDF for axiomatic
• Previous by thread: RE: XML / HTML Transport size
• Next by thread: Re: XML / HTML Transport size
• Index(es):
  • Date
  • Thread