> -----Original Message-----
> From: [mailto:]
> 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
