OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]

> i'm raising the issue simply because it should be hard, not easy, for 
> this to happen. 

I'm not sure how one could design a language in which it is possible but
difficult to write nested loops.

The other angle on this is that if you provide a high-level construct for
doing something complex, the system has more chance of optimizing it than if
you make the programmer code it by hand. For example, there were those who
argued that XQuery shouldn't offer the following-sibling axis because it's
hard to optimize. In answer to that: firstly, the efficiency of
following-sibling depends greatly on the internal data structures used to
implement the data model; and secondly, it's very much easier to optimize
$x/following-sibling::y than to optimize the construct the user would
otherwise be forced to write, $x/../y[.>>$x].

What is true, of course, is that high-level declarative languages like XSLT,
XQuery, SQL, and Prolog create the situation that it's difficult for
programmers to predict the performance of their programs without detailed
knowledge of the strategies used by the optimizer. For example, you have no
way of knowing from the language spec alone whether following-sibling::x[1]
will take constant time, or time proportional to the number of following
siblings (or potentially even something worse). I don't think this means
that such languages are a bad idea.

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






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS