inspect:functions performance
Sunday, 27 September 2015 · 5 messages · last reply 28 Sep 2015
AB
Andy Bunce27 Sep 2015 16:58 #
Hi, The following code runs (using v8.3) in about 1sec for me.
import module namespace p="xquery-30" at "
https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm
";
p:parse-XQuery("2+2")Using inspect:functions
let $f:= inspect:functions( "
https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm ")
[ local-name-from-QName(function-name(.)) = "parse-XQuery" and function-arity(.)=1]
return $f("2+2")
takes a very much longer time. Is this a bug?
/Andy
CG
Christian Grün28 Sep 2015 08:58 #
Hi Andy,
my first assumption was that it's the remote URI call that slows down the query. Then I noticed that it's due to the dynamic function calls that are generated by the second query.
It's always faster to call functions that are statically compiled. In the given case, as the imported XQuery 3.0 module nearly exclusively contains of function calls, this is more noticeable than for other use cases. However, it's an interesting example I haven't encountered so far, so we'll keep it in mind!
Christian
Quoted text · Andy Bunce · 20 lines
On Sun, Sep 27, 2015 at 4:58 PM, Andy Bunce <bunce.andy at gmail.com> wrote: > Hi, > The following code runs (using v8.3) in about 1sec for me. > > import module namespace p="xquery-30" at > "https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm"; > p:parse-XQuery("2+2") > > Using inspect:functions > > let $f:= inspect:functions( > "https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm") > [ local-name-from-QName(function-name(.)) = "parse-XQuery" > and function-arity(.)=1] > return $f("2+2") > > takes a very much longer time. > Is this a bug? > > /Andy
AB
Andy Bunce28 Sep 2015 10:39 #
The remote call was just to avoid a large email attachment. In my actual use case I have maybe a dozen similarly sized parsing modules. Would the best strategy be to put them in the repo and import all and select the required one via a switch statement? Or would eval work better or maybe some small Java piece? ... let $f:= java:compile($f) return $f("2+2")
/Andy
Quoted text · Christian Grün · 43 lines
On 28 September 2015 at 07:58, Christian Grün <christian.gruen at gmail.com> wrote: > Hi Andy, > > my first assumption was that it's the remote URI call that slows down > the query. Then I noticed that it's due to the dynamic function calls > that are generated by the second query. > > It's always faster to call functions that are statically compiled. In > the given case, as the imported XQuery 3.0 module nearly exclusively > contains of function calls, this is more noticeable than for other use > cases. However, it's an interesting example I haven't encountered so > far, so we'll keep it in mind! > > Christian > > > > On Sun, Sep 27, 2015 at 4:58 PM, Andy Bunce <bunce.andy at gmail.com> wrote: > > Hi, > > The following code runs (using v8.3) in about 1sec for me. > > > > import module namespace p="xquery-30" at > > " > https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm > "; > > p:parse-XQuery("2+2") > > > > Using inspect:functions > > > > let $f:= inspect:functions( > > " > https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm > ") > > [ local-name-from-QName(function-name(.)) = "parse-XQuery" > > and function-arity(.)=1] > > return $f("2+2") > > > > takes a very much longer time. > > Is this a bug? > > > > /Andy >
CG
Christian Grün28 Sep 2015 10:59 #
Quoted text · Andy Bunce · 3 lines
> Would the best > strategy be to put them in the repo and import all and select the required > one via a switch statement?
That's what I would usually recommend. If all modules are as large as the XQuery parser code, however, it may take too long to simply get them parsed. So it could indeed be worth trying xquery:eval…
Looking forward to your results, Christian
Quoted text · Andy Bunce · 105 lines
> let $f:= java:compile($f) > return $f("2+2") > > /Andy > > On 28 September 2015 at 07:58, Christian Grün <christian.gruen at gmail.com> > wrote: >> >> Hi Andy, >> >> my first assumption was that it's the remote URI call that slows down >> the query. Then I noticed that it's due to the dynamic function calls >> that are generated by the second query. >> >> It's always faster to call functions that are statically compiled. In >> the given case, as the imported XQuery 3.0 module nearly exclusively >> contains of function calls, this is more noticeable than for other use >> cases. However, it's an interesting example I haven't encountered so >> far, so we'll keep it in mind! >> >> Christian >> >> >> >> On Sun, Sep 27, 2015 at 4:58 PM, Andy Bunce <bunce.andy at gmail.com> wrote: >> > Hi, >> > The following code runs (using v8.3) in about 1sec for me. >> > >> > import module namespace p="xquery-30" at >> > >> > "https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm"; >> > p:parse-XQuery("2+2") >> > >> > Using inspect:functions >> > >> > let $f:= inspect:functions( >> > >> > "https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm") >> > [ local-name-from-QName(function-name(.)) = >> > "parse-XQuery" >> > and function-arity(.)=1] >> > return $f("2+2") >> > >> > takes a very much longer time. >> > Is this a bug? >> > >> > /Andy > > On Mon, Sep 28, 2015 at 10:39 AM, Andy Bunce <bunce.andy at gmail.com> wrote: > The remote call was just to avoid a large email attachment. In my actual use > case I have maybe a dozen similarly sized parsing modules. Would the best > strategy be to put them in the repo and import all and select the required > one via a switch statement? Or would eval work better or maybe some small > Java piece? > ... > let $f:= java:compile($f) > return $f("2+2") > > /Andy > > On 28 September 2015 at 07:58, Christian Grün <christian.gruen at gmail.com> > wrote: >> >> Hi Andy, >> >> my first assumption was that it's the remote URI call that slows down >> the query. Then I noticed that it's due to the dynamic function calls >> that are generated by the second query. >> >> It's always faster to call functions that are statically compiled. In >> the given case, as the imported XQuery 3.0 module nearly exclusively >> contains of function calls, this is more noticeable than for other use >> cases. However, it's an interesting example I haven't encountered so >> far, so we'll keep it in mind! >> >> Christian >> >> >> >> On Sun, Sep 27, 2015 at 4:58 PM, Andy Bunce <bunce.andy at gmail.com> wrote: >> > Hi, >> > The following code runs (using v8.3) in about 1sec for me. >> > >> > import module namespace p="xquery-30" at >> > >> > "https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm"; >> > p:parse-XQuery("2+2") >> > >> > Using inspect:functions >> > >> > let $f:= inspect:functions( >> > >> > "https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm") >> > [ local-name-from-QName(function-name(.)) = >> > "parse-XQuery" >> > and function-arity(.)=1] >> > return $f("2+2") >> > >> > takes a very much longer time. >> > Is this a bug? >> > >> > /Andy > >
AB
Andy Bunce28 Sep 2015 12:37 #
Looks like xquery:eval is best
let $s:='import module namespace p="xquery-30" at "
https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm
";
p:parse-XQuery("2+2")'
return xquery:eval($s)This almost seems to run faster than the direct import :-)
/Andy
Quoted text · Christian Grün · 136 lines
On 28 September 2015 at 09:59, Christian Grün <christian.gruen at gmail.com> wrote: > > Would the best > > strategy be to put them in the repo and import all and select the > required > > one via a switch statement? > > That's what I would usually recommend. If all modules are as large as > the XQuery parser code, however, it may take too long to simply get > them parsed. So it could indeed be worth trying xquery:eval… > > Looking forward to your results, > Christian > > > > let $f:= java:compile($f) > > return $f("2+2") > > > > /Andy > > > > On 28 September 2015 at 07:58, Christian Grün <christian.gruen at gmail.com > > > > wrote: > >> > >> Hi Andy, > >> > >> my first assumption was that it's the remote URI call that slows down > >> the query. Then I noticed that it's due to the dynamic function calls > >> that are generated by the second query. > >> > >> It's always faster to call functions that are statically compiled. In > >> the given case, as the imported XQuery 3.0 module nearly exclusively > >> contains of function calls, this is more noticeable than for other use > >> cases. However, it's an interesting example I haven't encountered so > >> far, so we'll keep it in mind! > >> > >> Christian > >> > >> > >> > >> On Sun, Sep 27, 2015 at 4:58 PM, Andy Bunce <bunce.andy at gmail.com> > wrote: > >> > Hi, > >> > The following code runs (using v8.3) in about 1sec for me. > >> > > >> > import module namespace p="xquery-30" at > >> > > >> > " > https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm > "; > >> > p:parse-XQuery("2+2") > >> > > >> > Using inspect:functions > >> > > >> > let $f:= inspect:functions( > >> > > >> > " > https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm > ") > >> > [ local-name-from-QName(function-name(.)) = > >> > "parse-XQuery" > >> > and function-arity(.)=1] > >> > return $f("2+2") > >> > > >> > takes a very much longer time. > >> > Is this a bug? > >> > > >> > /Andy > > > > > > On Mon, Sep 28, 2015 at 10:39 AM, Andy Bunce <bunce.andy at gmail.com> wrote: > > The remote call was just to avoid a large email attachment. In my actual > use > > case I have maybe a dozen similarly sized parsing modules. Would the best > > strategy be to put them in the repo and import all and select the > required > > one via a switch statement? Or would eval work better or maybe some small > > Java piece? > > ... > > let $f:= java:compile($f) > > return $f("2+2") > > > > /Andy > > > > On 28 September 2015 at 07:58, Christian Grün <christian.gruen at gmail.com > > > > wrote: > >> > >> Hi Andy, > >> > >> my first assumption was that it's the remote URI call that slows down > >> the query. Then I noticed that it's due to the dynamic function calls > >> that are generated by the second query. > >> > >> It's always faster to call functions that are statically compiled. In > >> the given case, as the imported XQuery 3.0 module nearly exclusively > >> contains of function calls, this is more noticeable than for other use > >> cases. However, it's an interesting example I haven't encountered so > >> far, so we'll keep it in mind! > >> > >> Christian > >> > >> > >> > >> On Sun, Sep 27, 2015 at 4:58 PM, Andy Bunce <bunce.andy at gmail.com> > wrote: > >> > Hi, > >> > The following code runs (using v8.3) in about 1sec for me. > >> > > >> > import module namespace p="xquery-30" at > >> > > >> > " > https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm > "; > >> > p:parse-XQuery("2+2") > >> > > >> > Using inspect:functions > >> > > >> > let $f:= inspect:functions( > >> > > >> > " > https://raw.githubusercontent.com/expkg-zone58/ex-xparse/master/src/main/content/parsers/xquery-30.xqm > ") > >> > [ local-name-from-QName(function-name(.)) = > >> > "parse-XQuery" > >> > and function-arity(.)=1] > >> > return $f("2+2") > >> > > >> > takes a very much longer time. > >> > Is this a bug? > >> > > >> > /Andy > > > > >
Written for BaseX 8.3. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery