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

RE: XML Performance in a Transacation and recursion


xsltproc performance
Writers of XSLT processors would be more inclined to take up this challenge
if you didn't state upfront that you needed an xsltproc solution!

Clearly this ought to work vastly better with the new string-handling
capabilities in XSLT 2.0.

But post the sample, and let's see what we can do with it. xsl-list might be
a better forum for this than xml-dev.

Michael Kay
http://www.saxonica.com/
 

> -----Original Message-----
> From: Rick Marshall [mailto:rjm@z...] 
> Sent: 03 April 2006 01:00
> To: Peter Hunsberger
> Cc: Michael Kay; xml-dev@l...; daniel@v...
> Subject: Re:  XML Performance in a Transacation and recursion
> 
> i've found the performance problem, and it ties together with the 
> discussion on recursion.
> 
> here's the problem - the stylesheet vocabulary is used to write a 
> postscript program. but postscript strings can't contain '(' 
> or ')' (the 
> delimiters for a postscript string).
> 
> so every output string has to be parsed and the parentheses 
> escaped with 
> a '\'.
> 
> we have no control over the source of the documents so i tried the 
> recursive examples for substituting one string with another through a 
> string. eg "ABC(DEF" ends up as "ABC\(DEF" and 
> "AB(DEF)GHI()JK(" ends up 
> as "AB\(DEF\)GHI\(\)JK\(".
> 
> i've solved my performance problem for the moment by 
> preprocessing the 
> input with sed instead.
> 
> but i'm not happy because sed has no knowledge of the dom and blindly 
> applies the transformation, instead of only applying it to 
> the content 
> of elements.
> 
> so here's a real challenge - write a template for the above 
> transformation with an example on how to call it; i'll put it 
> into the 
> style sheet and test it against the examples and we'll find out what 
> techniques are linear or better and what ones aren't.
> 
> the solution (in this case) must work with xsltproc.
> 
> currently on a 410k input document 41 of the 43 seconds of processing 
> time is taken up by the string escaping function.
> 
> writers of xsl processors can then compare their performance results 
> over the various techniques as well.
> 
> regards
> 
> rick
> 
> Peter Hunsberger wrote:
> 
> >On 3/26/06, Rick Marshall <rjm@z...> wrote:
> >  
> >
> >>Michael Kay wrote:
> >>
> >>    
> >>
> >>>>o(n2) is what you get when something is wrong.
> >>>>
> >>>>        
> >>>>
> >>>No, there are many problems for which no solution exists 
> that is better than
> >>>O(n^2) - in any language.
> >>>
> >>>
> >>>      
> >>>
> >>and it's a problem, because those problems can't be scaled, 
> but instead
> >>have to be tackled by decomposition (at least you then get 
> linear response)
> >>
> >>    
> >>
> >
> >Think about what you're saying here:  if you can break the data apart
> >by hand and  get linear processing times you've demonstrated that
> >there is an algorithm that has linear processing times. The issue is
> >coding it up...
> >
> >--
> >Peter Hunsberger
> >
> >
> >!DSPAM:44280618321021679284069!
> >
> >  
> >
> 



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.