unordered {} and fn:unordered()

[Michael Kay]

> That is an interesting point. Because I have always thought it more 
> important to optimize well written queries than badly written ones! 
> Let's assume I have the time to implement one optimization and can 
> choose between:
> 
> 1) An optimization that basically turns the badly written 
> query into the 
> well written query.
> 
> 2) An optimization that evaluates the well written query (only) in a 
> faster way.
> 
> I have usually chosen option 2, because it allows the user 
> (maybe with 
> some effort) to get a faster performing query, which for some 
> users is 
> very important. If I choose option 1, there is simply no way 
> at all for 
> the user to get the performance he could get with option 2.

Yes, it's an interesting trade-off. In the past, when I've worked on
software products that cost 6-figure sums and have a few hundred users, the
emphasis has always been on meeting the requirements of the top-end users
who were generating most of the revenue. When you've got tens of thousands
of users most of whom are producing no revenue at all, the emphasis is on
reducing the support requirement, which means trying to make the product
perform well out of the box even when the user hasn't read the manual.

Actually, I don't mind optimizing well-written queries. But I try to avoid
things that need performance hints - the vast majority of users won't know
how to use them. There are one or two examples of these in Saxon (memo
functions are an example) which are great for the handful of experts who
understand them, but they don't help you much when someone publishes a
benchmark comparison. Actually I think that if W3C wants to standardize
performance hints, memo functions would have been higher on my personal list
than unordered.

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