Xquery issue

Tuesday, 24 February 2015 · 4 messages
RS
Rob Stapper24 Feb 2015 12:43 #
Hi guys, While debugging a xquery-program I saw something strange behavior( to me anyway). I reproduced it in the attached xquery-snipped. Looking at the evaluation data in the query-info screen of the basexGUI after running the program, one can see that function $f($a) is evaluated more than ones. The result is ok but I wondered if this would reduce the performance. I'm running version 8.01 beta d13ddc7 in local GUI-mode. Regards, Rob Stapper --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. http://www.avast.com
DK
Dirk Kirsten24 Feb 2015 12:52 #
Hello Rob, well, it is interesting that the optimizer is optimizing away every second function call. However, the problem here seems to be introduced solely by prof:dump() and I actually can understand that optimizing this is more complicated. Not saying that it couldn't be optimized (Christian know far, far more about this than I do), but if remove thr prof:dump() the query is optimized to the query "16", which I guess can't be further optimized. And seeing that prof functions are for profiling and debugging and are usually not used in production, I think this could be considered a very minor issue. Cheers Dirk
Quoted text · Rob Stapper · 34 lines
On 02/24/2015 12:43 PM, Rob Stapper wrote: > Hi guys, > > > > While debugging a xquery-program I saw something strange behavior( to me > anyway). > > I reproduced it in the attached xquery-snipped. > > Looking at the evaluation data in the query-info screen of the basexGUI > after running the program, one can see that function $f($a) is evaluated > more than ones. > > The result is ok but I wondered if this would reduce the performance. > > > > I'm running version 8.01 beta d13ddc7 in local GUI-mode. > > > > Regards, > > > > Rob Stapper > > > > --- > Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. > http://www.avast.com >
-- Dirk Kirsten, BaseX GmbH, http://basexgmbh.de |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
CG
Christian Grün24 Feb 2015 16:56 #
Hi Rob, I can only confirm what Dirk said: If a query contains trace or prof:dump calls, it will be evaluated differently than calls without profiling code. In productive environments, it's usually advisable to get rid of those calls, or use global $DEBUG variables, as shown in the following example:
  declare variable $DEBUG := false();
  declare function local:debug($a) {
    if($DEBUG) then trace($a) else $a
  };
  local:debug(123)
Still, I'm thankful for your code snippet, as it allowed us to trace a minor intricate bug in the FLWOR optimizations. In some cases, only a part of the unused let clauses were removed from the query. Cheers, Christian
Quoted text · Dirk Kirsten · 52 lines
On Tue, Feb 24, 2015 at 12:52 PM, Dirk Kirsten <dk at basex.org> wrote: > Hello Rob, > > well, it is interesting that the optimizer is optimizing away every second function call. However, the problem here seems to be introduced solely by prof:dump() and I actually can understand that optimizing this is more complicated. Not saying that it couldn't be optimized (Christian know far, far more about this than I do), but if remove thr prof:dump() the query is optimized to the query "16", which I guess can't be further optimized. > > And seeing that prof functions are for profiling and debugging and are usually not used in production, I think this could be considered a very minor issue. > > Cheers > Dirk > > On 02/24/2015 12:43 PM, Rob Stapper wrote: >> Hi guys, >> >> >> >> While debugging a xquery-program I saw something strange behavior( to me >> anyway). >> >> I reproduced it in the attached xquery-snipped. >> >> Looking at the evaluation data in the query-info screen of the basexGUI >> after running the program, one can see that function $f($a) is evaluated >> more than ones. >> >> The result is ok but I wondered if this would reduce the performance. >> >> >> >> I'm running version 8.01 beta d13ddc7 in local GUI-mode. >> >> >> >> Regards, >> >> >> >> Rob Stapper >> >> >> >> --- >> Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. >> http://www.avast.com >> > > -- > Dirk Kirsten, BaseX GmbH, http://basexgmbh.de > |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz > |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: > | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle > `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 >
RS
Rob Stapper24 Feb 2015 17:34 #
Hi Christain and Dirk, Thanx again for your thorough reply and for the code-snippet. After debugging and my code works fine again I always get rid of all trace- and prof:dump-statements. Regards, Rob -----Oorspronkelijk bericht-----
Quoted text · Christian Grün · 70 lines
Van: Christian Grün [mailto:christian.gruen at gmail.com] Verzonden: dinsdag 24 februari 2015 16:57 Aan: Dirk Kirsten CC: Rob Stapper; BaseX Onderwerp: Re: [basex-talk] Xquery issue Hi Rob, I can only confirm what Dirk said: If a query contains trace or prof:dump calls, it will be evaluated differently than calls without profiling code. In productive environments, it's usually advisable to get rid of those calls, or use global $DEBUG variables, as shown in the following example: declare variable $DEBUG := false(); declare function local:debug($a) { if($DEBUG) then trace($a) else $a }; local:debug(123) Still, I'm thankful for your code snippet, as it allowed us to trace a minor intricate bug in the FLWOR optimizations. In some cases, only a part of the unused let clauses were removed from the query. Cheers, Christian On Tue, Feb 24, 2015 at 12:52 PM, Dirk Kirsten <dk at basex.org> wrote: > Hello Rob, > > well, it is interesting that the optimizer is optimizing away every second function call. However, the problem here seems to be introduced solely by prof:dump() and I actually can understand that optimizing this is more complicated. Not saying that it couldn't be optimized (Christian know far, far more about this than I do), but if remove thr prof:dump() the query is optimized to the query "16", which I guess can't be further optimized. > > And seeing that prof functions are for profiling and debugging and are usually not used in production, I think this could be considered a very minor issue. > > Cheers > Dirk > > On 02/24/2015 12:43 PM, Rob Stapper wrote: >> Hi guys, >> >> >> >> While debugging a xquery-program I saw something strange behavior( to >> me anyway). >> >> I reproduced it in the attached xquery-snipped. >> >> Looking at the evaluation data in the query-info screen of the >> basexGUI after running the program, one can see that function $f($a) >> is evaluated more than ones. >> >> The result is ok but I wondered if this would reduce the performance. >> >> >> >> I'm running version 8.01 beta d13ddc7 in local GUI-mode. >> >> >> >> Regards, >> >> >> >> Rob Stapper >> >> >> >> --- >> Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. >> http://www.avast.com >> > > -- > Dirk Kirsten, BaseX GmbH, http://basexgmbh.de > |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz > |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: > | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle > `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 > --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. http://www.avast.com

⚡Generated with XQuery