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