[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] Is it time for the binary XML permathread to start up again?
- From: Alessandro Triglia <sandro@mclink.it>
- To: noah_mendelsohn@us.ibm.com, xml-dev@lists.xml.org
- Date: Fri, 20 Jul 2007 23:22:01 +0200
> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]