It would be good to see what the bigger picture is, i.e. what is the input and
output of the query. There might be a much better way of tackling it. It's not
clear, for example, whether addition to the list really needs to be incremental
in this manner, or whether it can be done in a functional mapping from the
input.
If it does need to be incremental, then using the new feature of maps (present
in some XQuery 3.0 implementations, though not in the spec) will certainly
increase the likelihood of the query performing well. Alternatively, it might
well be possible to add items to the list unconditionally, and then remove
duplicates by using distinct-values(), which would reduce the risk of quadratic
performance although it might increase memory requirements.
Dana is quite right that with this kind of query, no optimizer is going to do a
perfect job. It's one of the paradoxes of optimization that achieving good
performance depends on understanding what the optimizer can and can't do. For
example, if the data volumes are large and there are many duplicates then
Saxon-EE will do a much better job if the body of David's function is rewritten
to the equivalent
if (exists($list[.=$item])) then $list else ($list, $item)
Of course the optimizer doesn't know how long the list will be or how much of
the time the new item will be a duplicate, so it can't do a perfect job all of
the time. It's because of this difficulty of "gaming the optimizer" that I'm
generally in favour of providing users with more control over performance by
providing data structures such as maps (XSLT has always provided keys, which
are a similar concept). But I remain an enthusiast for pure functional
programming; the more I see it in action, the more I feel it is the right
solution for 90% of the code we write. Providing data structures with
predictable performance isn't inconsistent with functional programming.
(You might ask why this version performs better, and if so, why doesn't Saxon
do the rewrite itself? The answer is that without volumetric information, the
optimizer has to make guesses. 9 times out of 10, when the user writes ($a =
$b), then even if static type analysis can't prove it, the chances are that
both $a and $b will be singletons. Whereas if they write $a[. = $b], the
chances are that $a is a sequence. So the optimizer is making pure guesses
based on observed behaviour rather than hard data - and by doing so, is
reinforcing that behaviour. It's a black art.)
Michael Kay
Saxonica
On 15 May 2013, at 16:05, David Lee wrote:
> In XQuery (neglecting some vendor specific extensions) variables are imutable.
> Thus it is counter-productive to think "I have a list then I want to add to
> it"
> Rather thing "I have a function which I wish to produce a final list"
>
> Like this
>
> declare function addlist( $list as xs:string* , $item as xs:string) as
> xs:string*
> {
> if( $item = $list ) then $list else ( $list , $item )
>
> };
>
> let $list := addlist( () , "apples" ) ,
> $list := addlist( $list , "pears" ),
> $list := addlist( $list , "peaches" ),
> $list := addlist( $list , "apples" ),
> $list := addlist( $list , "pumpkins" )
> return $list
>
> This *looks like* it is adding values to $list but in fact it is assigning a
> new variable called $list for every expression
> based on the previous value and possibly adding one more.
>
>
>
>
>
>
>
>
>
>
>
>
> ----------------------------------------
> David A. Lee
> [email protected]
> http://www.xmlsh.org
>
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Kunal Chauhan
> Sent: Wednesday, May 15, 2013 10:48 AM
> To: [email protected]
> Subject: [xquery-talk] Is it possible to maintain a list of value in XQuery
>
> Hi,
>
> I want to maintain a list of value.
>
> for eg:
> initially I have blank list and through some process I add values in to the
> list.
>
> like (Apple,Banana,Cherry)
>
> now, when get Apple as an output 2nd time it will check into the list.
> If present than don't add value into the list otherwise add it.
> At last I will return the list.
>
> I don't know whether it's possible or not.
> But this there any work around.
>
> Thanks and Regards,
>
> --
> Kunal Chauhan
> [email protected]
> [+918655517141]
> [+919904983614]
> _______________________________________________
> [email protected]
> http://x-query.com/mailman/listinfo/talk
_______________________________________________
[email protected]
http://x-query.com/mailman/listinfo/talk
