[
Lists Home |
Date Index |
Thread Index
]
Benjamin Franz wrote:
> On Mon, 18 Nov 2002, James Clark wrote:
>>Hmmm. What about
>>
>> http://www.research.att.com/sw/tools/xmill/
>
> Nice try - but no cigar.
>
> Using a real file from my office (I chose a nice big one at random to
> test):
>
> -rw-rw---- 1 snowhare snowhare 7267803 Nov 18 07:15 recipes.xml
> -rw-rw-r-- 1 snowhare snowhare 1993131 Nov 18 07:15 recipes.xmi
> -rw-rw---- 1 snowhare snowhare 1922919 Nov 18 07:15 recipes.xml.bz2
>
> So, the _optimized_ XML compressor did more poorly than a default general
> purpose compressor by a few percentage points (at least for this data).
> Their description sounds remarkably similiar to a block sort compressor -
> which is _precisely_ what bzip2 is (minus the 'patent rights' language
> from AT&T ;) ). Which is probably why the end sizes are fairly close for
> both.
That's an interesting benchmark, though one normally runs such tests on
several different files as you can always find cases that are
pathological to one algo and not to another. XML aware compressors also
tend to do better compared to general compressors on files that are
highly structured more than on files that contain a lot of text.
How well does gzip fare on this? bzip2 is frequently discarded here due
to the massive amount of processing that it requires, which makes it
almost useless on limited devices as you'd spend the time you gained in
bandwidth uncompressing the stream.
Do you have that file available somewhere? I'm always curious to see how
well BiX compares in various situations :)
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
