[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 agai

• From: Alessandro Triglia <sandro@m...>
• To: xml-dev@l..., petexmldev@t...
• Date: Sat, 21 Jul 2007 15:09:06 +0200

 
> -----Original Message-----
> From: Pete Cordell [mailto:petexmldev@t...] 
> Sent: Saturday, July 21, 2007 06:42
> 
> Since the amount of data being compressed is smaller than the 
> pure gzip case, and possibly the compressor has shorter runs 
> of characters to choose between for optimal compression, I 
> wouldn't be surprised if FI + gzip was actually faster than 
> gzip alone.
> 
> I think there is sufficient variables here that a measurement 
> is required rather than an assumption.  Unfortunately I'm not 
> in a position to make such a measurement!


Yes, but in the typical use case for FI you have an infoset (in some in-memory representation) to transfer, not an XML document to transfer. You serialize your infoset into a FI document and send the FI document to your recipient. The question is whether it makes sense for you to zip your FI document before sending it.  This extra step will usually take some processing time (on both the sender side and the recipient side), and so the question is: which is more important for the sender and the recipient: saving the extra time or saving the extra bytes?  Consider that your FI document is much smaller than an equivalent XML serialization would have been, and therefore it may be already "small enough" for your situation.

But I totally agree that, when you have an XML document to transfer, FI+gzip can be faster than gzip alone.  In fact, that is very likely in the case of a recipient who will have to process the incoming message but has no specific requirement to convert it back to XML.  This is because "gzip alone" actually means "unzipping+XML parsing" while "FI+gzip" means "unzipping+FI parsing" for the recipient.

Alessandro Triglia