[
Lists Home |
Date Index |
Thread Index
]
On Tue, 2004-04-20 at 12:45, Stephen D. Williams wrote:
> David Megginson wrote:
>
> > Stephen D. Williams wrote:
> >
> >> Processing overhead, including the major components of parsing /
> >> object creation / data copies / serialization, is not a 'future
> >> problem'. It has always been a problem.
> >
> > We don't know how much and what kind of a problem XML will be until we've
> > had time to gain experience -- if we try to optimize too early, we'll
> > end up
> > optimizing the wrong thing.
>
> I suppose "early" and "time to gain experience" are relative.
>
> > For example, I set up a test for a customer a while back to see how fast
> > Expat could parse documents. On my 900 MHz Dell notebook, with 256MB RAM
> > and Gnome, Mozilla, and XEmacs competing for memory and CPU, Expat could
> > parse about 3,000 1K XML documents per second (if memory does not fail
> > me).
> > If I had tried to, say, build DOM trees from that, I expect that the
> > number
> > would have fallen into the double digits (in C++) or worse. In this
> > case,
> > obviously, there would be far more to be gained from optimizing the
> > code on
> > the other side of the parser (say, by implementing a reusable object
> > pool or
> > lazy tree building) than there would be from replacing XML with something
> > that parsed faster.
>
> Why make the assumption that "optimizing the code on the other side of
> the parser" is the first or only step? I posit that this is not the
> best way to proceed and artificially narrows possible solutions. The
> steps needed to parse XML, such as processing Expat events, cause a
> minimum amount of work. When that data has been parsed, it must be in a
> usable form and data in a usable form must be serialized at some point.
that's a big claim. and i don't agree even a little bit.
<snip/>
|
