xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject Re: [spinnaker] Announce
Date Wed, 12 Jul 2000 21:44:52 GMT

> would you trade (a little) performance for a healthy and open community
> of developers?

Um, perhaps.  But the whole concept of XML already has performance issues.
Especially with a parser, people (users, products) don't really care about
the code... they need it to be fast enough to please.  Even the fastest
possible parsers may have problems pleasing, esp. since it really looks
like XML is totally taking over the world, and will have to please a very
large constituency.  (I'm down in Florada at the MS developers conference
right now, where they are unveiling there .NET architecture, which is
totally XML based).

I'm well aware of the different constraints of open source vs. commercial
development.  If the parser folks do their job right, hopefully we can have
both optimal performance and understandable code, but I would still put
performance a notch higher, or at least bound to the fact that it must be
commercially viable from a performance perspective (the same is true for
the Apache HTTP server, I assume).  If it ain't fast enough, nothing else
matters.  Just my opinion, based on my perspective.

The best optimizations often come from algorithmic tuning, rather than code
tricks, and these kind of optimizations, especially at the stage that
Xerces and Xalan are at, are helped, rather than hindered by clean,
understandable code.  Knowing you, I'm pretty certain that we are in
violent agreement on this.  On the other hand, there may be system level
complexity introduced by these algorithmic tunings, like the use of string
pools in Xerces.  Do you suggest that Xerces shouldn't use string pooling?
Mime
View raw message