inspect:functions performance

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 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 >

> Would the best > strategy be to put them in the repo and import all and select the required > one via a switch statement?

> 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 > >

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 > > > > >