[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "Binary XML" proposals
- From: Ramin Firoozye <firstname.lastname@example.org>
- To: The Deviants <email@example.com>
- Date: Tue, 10 Apr 2001 00:18:47 -0700
> At 12:22 PM 08/04/01 +0600, Danny Ayers wrote:
> > Ok, so if you put all this together,
> >what would you be gaining? Say an order or two of magnitude of
> speed? (and
> >the same kind of gains for data storage)
> The world may have a place for binary XML, but the above is not an
> argument for it. First of all, an argument that unpacking a
> binary format (particularly on a machine whose binaries are
> different and you have to bit-swizzle) is significantly faster than
> XML parsing a la expat or MSXML, needs to supported by actual
> empirical data rather than by assertion. And suppose, as a thought
> experiment, that this were true; if you were to speed up the
> XML parsing/generating part of an XML-using application, how much
> would that speed up the whole application? You'd need to know
> what proportion of its time it spends parsing/generating XML. In
> some apps, this proportion is going to be very small.
> As for the data storage volume issue, uh, isn't the world awash
> in admirable compression technology that works pretty well on
> most data formats, and particularly well on redundant textual
> stuff like XML?
> Absent some good strong empirical evidence, neither processing
> nor storage cost are a priori arguments for going binary.
I must have missed something. I thought the original discussion was about
representing binary image data in XML... I've got to keep up a little
There actually is a good reason for binarizing XML. In small footprint
situations (like phone or PDA browsers) or embedded devices, a full-size XML
(or XSL) parser may be prohibitive.
In most cases, however it doesn't provide much advantage. Binarizing of the
form in WML does actually make the content smaller--but that's because
they've already pre-defined the element tokens, well-known attributes, and
common substrings. Binarizing streaming XML of an unknown variety actually
slows down the application because of the overhead for building an
on-the-fly dictionary (and in worst-case scenarios--requiring multiple
passes over the source). Binarizing through object-streaming actually makes
the file size larger due to overhead for storing internal tree information.
Loading up binary data does save a relatively small amount of time over
parsing, but as Tim says, it should be viewed in the context of the overall
application performance. We tried binarizing XML and XSL inside an XSL
engine last year. The performance improvements were negligible in view of
all the other work the XSL engine had to do.
Ramin Firoozye - Wizen Software