• From: Alessandro Triglia <sandro@m...>
• To: noah_mendelsohn@u..., xml-dev@l...
• Date: Fri, 20 Jul 2007 23:22:01 +0200

 

> -----Original Message-----
> From: noah_mendelsohn@u... [mailto:noah_mendelsohn@u...] 
> Sent: Friday, July 20, 2007 16:28
> 
> Alessandro Trigila writes:
> 
> > Fast Infoset doesn't try to be extremely tightly coded.  We 
> tried to 
> > find a good balance between ease of implementation, 
> encoding/decoding 
> > speed, and compactness.  So there is still room for gzip to remove 
> > some of the residual redundancy.
> 
> OK, that makes a lot of sense.  Still, one has to be careful. 
>  There's a line of reasoning that goes:
> 
> a) Fast Infoset is only secondarily about compactness; it's 
> about speed.


I would say it tries to optimize both while keeping implementation easy.


> That's why there's still redundancy that gzip can find.
> b) If we're willing to take the result of what we computed 
> quickly and run it through gzip, we can make it small after 
> all, but then it will be slower.
> 
> That's not to say that in the 2dimensional space vs. time 
> plane you might not wind up for some purpose at a happy 
> compromise by running FI and gzip, but it's far from obvious 
> in advance that the two are complementing rather 
> than diluting each others' best qualities in general.   Would 
> I be right 
> in guessing that you shouldn't even consider doing the gzip 
> step if you're interested mainly in reducing CPU overhead?


I agree.  

Alessandro