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

RE: Is it time for the binary XML permathread to start up aga

• From: noah_mendelsohn@u...
• To: "Alexander Philippou" <alex@n...>
• Date: Fri, 20 Jul 2007 17:28:06 -0400

Thanks, but I think you missed my point.  I assume that the reason people 
would use FI without gzip is mainly for speed.  I'm asking, when they use 
FI+gzip as shown below to get that extra 15% in space compared to gzip by 
itself, am I right that they lose a lot of the speed advantage that FI 
gave them originally?  I'm not saying this is bad.  I'm suggesting:

        FI:  good speed, moderate compression
        gzip:  very good compression, slow
        FI + gzip: slightly better compression than gzip, slightly slower 
than gzip

None of these combinations provides very tight encoding with very high 
speed.  Am I right? 

Thanks.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Alexander Philippou" <alex@n...>
07/20/2007 04:33 PM
 
        To:     <noah_mendelsohn@u...>, "'Costello, Roger L.'" 
<costello@m...>, <xml-dev@l...>
        cc: 
        Subject:        RE:  Is it time for the binary XML 
permathread to start up  again?


> If gzip is going to make the FI form larger, or not much
> smaller, then 
> it's a bad use of time to run it, even if the time to gzip the FI is 
> indeed much lower than the time to gzip the original text.

Generally, compressing FI results in similar or smaller size than
compressing text. So the FI benefits are there both w/ and w/o 
compression.
Take the 27 files in MITRE / OVAL / Platform Data File Downloads as an
example:

text: 16,271,427 bytes
fi: 4,171,861 bytes (ratio 1:0.26)
text+gzip: 1,082,750 bytes (ratio 1:0.07)
fi+gzip: 867,648 bytes (ratio 1:0.05)

> Noah Mendelsohn

Alexander

• References:
  • RE: Is it time for the binary XML permathread to start up again?
    • From: "Alexander Philippou" <alex@n...>