RE: [xml-dev] XML Performance in a Transacation

[Tatu Saloranta <cowtowncoder@yahoo.com>]

--- Michael Kay <mike@saxonica.com> wrote:

> > A new performance oriented parser implementation
> must come with a  
> > straightforward API, or else it will matter little
> in practise.
> 
> I agree strongly with this sentiment. It's
> performance in the hands of the
> average user that's important, not performance in
> the hands of benchmarking
> gurus.

Important part of this, too, is a sensible layering of
components: very few drivers know much about the car
engine itself, and tuning/maintenance is generally
left to professionals. As such, having highly
specialized low-level components does not in and of
itself defeat the end goal of higher performance
processing pipelines. To me there are somewhat natural
stacking orders; streaming parser -> tree models ->
processors modifying tree models; and pipelining at
appropriate levels. There is nothing more frustrating
than reading about developers who pipeline xml
processing by full serialization  back to text, and
reparsing; just to go from, say, DOM to JDOM.

It can also prevent the problem of "swiss pocket
knife" solutions that try to do everything for
everyone (about the biggest concern I'd have
regarding, say, Xerces, is its multiple goals from
tree models to streaming parsing, xml, wml AND html,
and so forth), when different tools/libs can focus on
the slice they are in best position to deal with.
That's of course where well-designed interfaces are
needed (as you and Wolfgang pointed out).

For what it's worth, I also think that better
awareness of simple usage patterns for existing APIs
would help a lot. For APIs like SAX and StAX, the
number of rules to follow is quite small, albeit none
of the rules is necessarily immediately intuitive
without some knowledge of parser implementations in
general.

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com