[xquery-talk] Re: Optimizations

Fri Oct 3 16:50:46 PDT 2008

It's now handling this case. It was actually doing the final optimization
pass, the problem was that the "compareToInteger" expression, which is only
introduced by the optimizer in a previous phase, wasn't being recognized as
a candidate for further rewrite when the second operand became constant.

Optimizers only improve by trying them out on new test cases, so it's always
good to get feedback like this.

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

  _____  

From: remidewitte at gmail.com [mailto:remidewitte at gmail.com] On Behalf Of Rémi
Dewitte
Sent: 03 October 2008 15:38
To: Michael Kay
Cc: talk at x-query.com
Subject: Re: [xquery-talk] Re: Optimizations

Thanks Michael for these explanations,
It is very good to know these details. And a good motivation to buy
Saxon-SA.

Rémi

On Fri, Oct 3, 2008 at 4:27 PM, Michael Kay <mike at saxonica.com> wrote:

This is a case where Saxon (even Saxon-SA) has stopped optimizing when it
could have achieved a little more. The relevant part of the final expression
tree is

     <return>
        <sequence>
          <choose>
            <when>
              <compareToInteger op="ge" value="4"> 

                <literal value="3" type="xs:integer"/>

              </compareToInteger>
            </when>
            <then>
              <directElement name="debug" validation="preserve">
                <variableReference name="dosmthg"/>
              </directElement>
            </then>
          </choose> 

          <variableReference name="dosmthg"/>
        </sequence>
      </return>

and it hasn't noticed that the <when> condition is now constant.

Deciding when to stop optimizing is the trickiest part of the exercise - if
you go on too long, optimization can take longer than any run-time savings
it is delivering. In this occasion, two more passes would have paid
dividends - one to evaluate the <when> condition, the other to reduce the
<choose> to ().

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

  _____  

From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf
Of Rémi Dewitte

Sent: 03 October 2008 14:24 

To: talk at x-query.com

Subject: [xquery-talk] Re: Optimizations

Hi again,

In the same spirit, this is not at all optimized.
Maybe I need Saxon SA ?

declare variable $level as xs:integer := 3 ;

declare function local:debug($l as xs:integer,$what){
  if($l >=4) then
    <debug>{$what}</debug>
  else ()
};

let $dosmthg := <oki>test trace</oki>

return
(local:debug($level,$dosmthg),$dosmthg)

Rémi

On Fri, Oct 3, 2008 at 3:17 PM, Rémi Dewitte <remi at gide.net> wrote:

Hi,

I have made a little experiment after reading Michael (Kay) blog posts about
optimizations and recent James Fuller article.

I have a question quite specific to saxon still interesting in general.

Why in the following example even the function call is not skipped ?

XQuery is ::

declare variable $level := 3;

declare function local:debug($what){
  if($level >=4) then
    <debug>{$what}</debug>
  else ()
};

let $dosmthg := <oki>test trace</oki>

return
(local:debug($dosmthg),$dosmthg)

When I run saxon with -explain we get 

<query>
  <globalVariables>
    <declareVariable name="level">
      <literal value="3" type="xs:integer"/>
    </declareVariable>
  </globalVariables>
  <declareFunction name="local:debug" tailRecursive="false">
    <literal value="()"/>
  </declareFunction>
  <body>
    <let variable="dosmthg" as="element(oki,
{http://www.w3.org/2001/XMLSchema}untyped
<http://www.w3.org/2001/XMLSchema%7Duntyped> )">
      <be>
        <directElement name="oki" validation="skip">
          <valueOf>
            <literal value="test trace" type="xs:string"/>
          </valueOf>
        </directElement>
      </be>
      <return>
        <sequence>
          <functionCall name="local:debug" tailCall="false">
            <variableReference name="dosmthg"/>
          </functionCall>
          <variableReference name="dosmthg"/>
        </sequence>
      </return>
    </let>
  </body>
</query>

Cheers,
Rémi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20081003/c626ac0e/attachment-0001.htm