some questions over the profile module

> 1) The following code > declare function local:sequence($nb){for $i in 1 to xs:integer($nb) return > $i}; > prof:time(fn:count(local:sequence(1000000000000000000))) > return 4.94 ms.

> 2) It seems that you somehow call the fn:trace function in the profile > module. Is there a way to catch the returned values of these functions?

> the InfoView will give you some hints what’s going on

>Currently no. You can use the prof:current-ns()

> Hi Jean-Marc, > > > 1) The following code > > declare function local:sequence($nb){for $i in 1 to xs:integer($nb) > return > > $i}; > > prof:time(fn:count(local:sequence(1000000000000000000))) > > return 4.94 ms. > > the InfoView will give you some hints what’s going on. The reason is > that your code is compiled and simplified to the following query.. > > prof:time(fn:count((1 to 1000000000000000000))) > > ...which can then be evaluated in constant time. > > > > 2) It seems that you somehow call the fn:trace function in the profile > > module. Is there a way to catch the returned values of these functions? > > Currently no. You can use the prof:current-ns() function instead: > > let $start := prof:current-ns() > let $void := prof:void((1 to 10000000)[. = 1]) > let $end := prof:current-ns() > let $ms := ($end - $start) div 1000000 > return $ms || ' ms' > > Hope this helps, > Christian >

>>Currently no. You can use the prof:current-ns() > I thought about this one, but isn't this method less accurate than prof:time

> basex -o result.txt -r 10000 -V 1

On Thu, Dec 5, 2013 at 11:39 AM, Christian Grün <christian.gruen at gmail.com> wrote: > Hi Jean-Marc, > >>>Currently no. You can use the prof:current-ns() >> I thought about this one, but isn't this method less accurate than prof:time > > If your measurements don’t fall below milliseconds, it should make no > difference. > > Benchmarking is a complex field on its own, however: > > • In BaseX, it’s advisable to do all measurements with a running > server instance. Otherwise, your measurement will also include the > starup time for initializing the JVM and doing just-in-time > compilations. > > • If you use the GUI, those effects will also be amortized after a > while, but the visual processing of the query results may take some > additional time. > > • You can measure the number of multiple runs via the RUNS option [1]. > The following call on command line runs the query "1" for 10,000 > times: > >> basex -o result.txt -r 10000 -V 1 > ... > Parsing: 0.06 ms (avg) > Compiling: 0.0 ms (avg) > Evaluating: 0.0 ms (avg) > Printing: 0.03 ms (avg) > Total Time: 0.1 ms (avg) > ... > Query executed in 0.1 ms (avg). > > Please note that only the results of the first run will be output, so > this option should only be used when the output is small. As you have > probably seen, the output can also be “swallowed” via prof:dump(). > Some little experiments will soon give you a feeling on what’s > comparable and what’s not. > > If you want to compare the timing with other XQuery implementations, > it gets even more complicated, because each engine has its own timing > output, optimizations to speed up several runs, etc. In this case, a > simple call on command line gives you results that may still be best > comparable. > > Hope this helps, > Christian > > [1] http://docs.basex.org/wiki/Options#RUNS

> it is advisable to remove all trace() calls from the code before doing

> Hi Jean-Marc, > > another note (I just spotted your mail on talk at xquery.com; thanks for > making your code public!): it is advisable to remove all trace() calls > from the code before doing performance comparisons. > > Looking forward to your experiences, > Christian > ___________________________ > > On Thu, Dec 5, 2013 at 11:39 AM, Christian Grün > <christian.gruen at gmail.com> wrote: > > Hi Jean-Marc, > > > >>>Currently no. You can use the prof:current-ns() > >> I thought about this one, but isn't this method less accurate than > prof:time > > > > If your measurements don’t fall below milliseconds, it should make no > > difference. > > > > Benchmarking is a complex field on its own, however: > > > > • In BaseX, it’s advisable to do all measurements with a running > > server instance. Otherwise, your measurement will also include the > > starup time for initializing the JVM and doing just-in-time > > compilations. > > > > • If you use the GUI, those effects will also be amortized after a > > while, but the visual processing of the query results may take some > > additional time. > > > > • You can measure the number of multiple runs via the RUNS option [1]. > > The following call on command line runs the query "1" for 10,000 > > times: > > > >> basex -o result.txt -r 10000 -V 1 > > ... > > Parsing: 0.06 ms (avg) > > Compiling: 0.0 ms (avg) > > Evaluating: 0.0 ms (avg) > > Printing: 0.03 ms (avg) > > Total Time: 0.1 ms (avg) > > ... > > Query executed in 0.1 ms (avg). > > > > Please note that only the results of the first run will be output, so > > this option should only be used when the output is small. As you have > > probably seen, the output can also be “swallowed” via prof:dump(). > > Some little experiments will soon give you a feeling on what’s > > comparable and what’s not. > > > > If you want to compare the timing with other XQuery implementations, > > it gets even more complicated, because each engine has its own timing > > output, optimizations to speed up several runs, etc. In this case, a > > simple call on command line gives you results that may still be best > > comparable. > > > > Hope this helps, > > Christian > > > > [1] http://docs.basex.org/wiki/Options#RUNS >

> Hi Christian, > > Thx for your answer. > > it is advisable to remove all trace() calls from the code before doing > performance comparisons. > > You're right. From another side, the trace functions are called very few > times (68 calls), compared to the time execution (about two minutes to run > the entire test). This should be of small impact over the results. > > A remark over this test : I noticed that the test is running slower when I > disabled the options INLINELIMIT = 0 and TAILCALL = -1. > > > > 2013/12/5 Christian Grün <christian.gruen at gmail.com> > >> Hi Jean-Marc, >> >> another note (I just spotted your mail on talk at xquery.com; thanks for >> making your code public!): it is advisable to remove all trace() calls >> from the code before doing performance comparisons. >> >> Looking forward to your experiences, >> Christian >> ___________________________ >> >> On Thu, Dec 5, 2013 at 11:39 AM, Christian Grün >> <christian.gruen at gmail.com> wrote: >> > Hi Jean-Marc, >> > >> >>>Currently no. You can use the prof:current-ns() >> >> I thought about this one, but isn't this method less accurate than >> prof:time >> > >> > If your measurements don’t fall below milliseconds, it should make no >> > difference. >> > >> > Benchmarking is a complex field on its own, however: >> > >> > • In BaseX, it’s advisable to do all measurements with a running >> > server instance. Otherwise, your measurement will also include the >> > starup time for initializing the JVM and doing just-in-time >> > compilations. >> > >> > • If you use the GUI, those effects will also be amortized after a >> > while, but the visual processing of the query results may take some >> > additional time. >> > >> > • You can measure the number of multiple runs via the RUNS option [1]. >> > The following call on command line runs the query "1" for 10,000 >> > times: >> > >> >> basex -o result.txt -r 10000 -V 1 >> > ... >> > Parsing: 0.06 ms (avg) >> > Compiling: 0.0 ms (avg) >> > Evaluating: 0.0 ms (avg) >> > Printing: 0.03 ms (avg) >> > Total Time: 0.1 ms (avg) >> > ... >> > Query executed in 0.1 ms (avg). >> > >> > Please note that only the results of the first run will be output, so >> > this option should only be used when the output is small. As you have >> > probably seen, the output can also be “swallowed” via prof:dump(). >> > Some little experiments will soon give you a feeling on what’s >> > comparable and what’s not. >> > >> > If you want to compare the timing with other XQuery implementations, >> > it gets even more complicated, because each engine has its own timing >> > output, optimizations to speed up several runs, etc. In this case, a >> > simple call on command line gives you results that may still be best >> > comparable. >> > >> > Hope this helps, >> > Christian >> > >> > [1] http://docs.basex.org/wiki/Options#RUNS >> > >

> However I can't find the log left by fn:trace, or prof:time. Do you know > where these traces append in this configuration ?