[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML Performance in a Transacation

  • To: xml-dev@l...
  • Subject: RE: XML Performance in a Transacation
  • From: Tatu Saloranta <cowtowncoder@y...>
  • Date: Fri, 24 Mar 2006 13:26:37 -0800 (PST)
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RMQJl8lj6tLbPOkyBcT7a5jTv7BI0Ey3Xu1Dodv96LBQkON0S672kondXQO2MRw9J2k2/5h4yQPkbAXv/FrtG3PJsCKwfHukClfr0/HW0q/4rCf4tzrbR8I0BF4fwIQLmzTK4CHPrmdZMakvAqTSJGmeUCfqCeogDDA+k5m08xY= ;

RE:  XML Performance in a Transacation
--- Michael Kay <mike@s...> 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 

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.