Handling JAXP XPath API with variable references.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Handling JAXP XPath API with variable references.

Jorge Williams-2
Hello all,

I’m in a situation where I need to execute an XPath which contains a variable reference over and over again in a tight loop.  At each iteration in the loop the source document will be different and the variable may contain a different value.  Looking at the JavaDocs it seems I can’t use the XPath.compile to precompile the XPath because of the changing variable value and I therefore need to call evaluate on each iteration.  Is this true? If so, is there a big performance penalty  for doing this? ..and Is there a way around this in Saxon?

Thank you,

-jOrGe W.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Handling JAXP XPath API with variable references.

Michael Kay
As so often happens, the JAXP Javadoc documentation is ambiguous. It says

>Although variables may be mutable, that is, an application may wish to evaluate the same XPath expression more than once with different variable values, in the course of evaluating any single XPath expression, a variable's value must not change.

Saxon's interpretation of what it meant to say is:

>Although variables may be mutable, that is, an application may wish to evaluate the same XPath expression more than once with different variable values, in the course of a single evaluation of any XPath expression, a variable's value must not change.

A consequence is that the variable resolver isn't called until run-time, which means Saxon has no way of knowing what variables exist at compile time.

The JAXP mechanism makes it very difficult to do multi-threaded evaluation: that is, evaluating the same expression in two different threads with different variable values; essentially, you have to manage the concurrency yourself within the variable resolver.

The s9api interface is a much better fit to the Saxon (and XPath 2.0) architecture: you declare the names and types of the variables before compiling the expression, and you provide their values before evaluating the expression. Thread safety with the s9api interface is no problem.

Michael Kay
Saxonica


> On 14 Aug 2016, at 23:10, Jorge Williams <[hidden email]> wrote:
>
> Hello all,
>
> I’m in a situation where I need to execute an XPath which contains a variable reference over and over again in a tight loop.  At each iteration in the loop the source document will be different and the variable may contain a different value.  Looking at the JavaDocs it seems I can’t use the XPath.compile to precompile the XPath because of the changing variable value and I therefore need to call evaluate on each iteration.  Is this true? If so, is there a big performance penalty  for doing this? ..and Is there a way around this in Saxon?
>
> Thank you,
>
> -jOrGe W.
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Handling JAXP XPath API with variable references.

Jorge Williams-2
Thanks for your quick response…more inline...

> On Aug 15, 2016, at 3:39 AM, Michael Kay <[hidden email]> wrote:
>
> As so often happens, the JAXP Javadoc documentation is ambiguous. It says
>
>> Although variables may be mutable, that is, an application may wish to evaluate the same XPath expression more than once with different variable values, in the course of evaluating any single XPath expression, a variable's value must not change.
>
> Saxon's interpretation of what it meant to say is:
>
>> Although variables may be mutable, that is, an application may wish to evaluate the same XPath expression more than once with different variable values, in the course of a single evaluation of any XPath expression, a variable's value must not change.
>
> A consequence is that the variable resolver isn't called until run-time, which means Saxon has no way of knowing what variables exist at compile time.
>

Understood, and this opens a path forward.  Are there significant performance implications to Saxon not knowing variables at compile time?

> The JAXP mechanism makes it very difficult to do multi-threaded evaluation: that is, evaluating the same expression in two different threads with different variable values; essentially, you have to manage the concurrency yourself within the variable resolver.
>
> The s9api interface is a much better fit to the Saxon (and XPath 2.0) architecture: you declare the names and types of the variables before compiling the expression, and you provide their values before evaluating the expression. Thread safety with the s9api interface is no problem.
>

Got it. I’ll have to evaluate changes to JAXP implementation vs switching to s9api — this is an existing product, the only new thing is the variable evaluation, we’ve already built in support for pooling, etc to address the concurrency issue.

> Michael Kay
> Saxonica
>
>
>> On 14 Aug 2016, at 23:10, Jorge Williams <[hidden email]> wrote:
>>
>> Hello all,
>>
>> I’m in a situation where I need to execute an XPath which contains a variable reference over and over again in a tight loop.  At each iteration in the loop the source document will be different and the variable may contain a different value.  Looking at the JavaDocs it seems I can’t use the XPath.compile to precompile the XPath because of the changing variable value and I therefore need to call evaluate on each iteration.  Is this true? If so, is there a big performance penalty  for doing this? ..and Is there a way around this in Saxon?
>>
>> Thank you,
>>
>> -jOrGe W.
>>
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports. http://sdm.link/zohodev2dev
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Handling JAXP XPath API with variable references.

Michael Kay
>
> Understood, and this opens a path forward.  Are there significant performance implications to Saxon not knowing variables at compile time?

Well, it creates some fairly convoluted logic, but it probably doesn't cost all that much in performance terms. Of course because the types are unknown there's no scope for type-based optimization. The other cost is the Java-to-XDM conversion logic, which is completely dynamic because statically the only thing we know is that the value is a Java Object.

Michael Kay
Saxonica

>
>> The JAXP mechanism makes it very difficult to do multi-threaded evaluation: that is, evaluating the same expression in two different threads with different variable values; essentially, you have to manage the concurrency yourself within the variable resolver.
>>
>> The s9api interface is a much better fit to the Saxon (and XPath 2.0) architecture: you declare the names and types of the variables before compiling the expression, and you provide their values before evaluating the expression. Thread safety with the s9api interface is no problem.
>>
>
> Got it. I’ll have to evaluate changes to JAXP implementation vs switching to s9api — this is an existing product, the only new thing is the variable evaluation, we’ve already built in support for pooling, etc to address the concurrency issue.
>
>> Michael Kay
>> Saxonica
>>
>>
>>> On 14 Aug 2016, at 23:10, Jorge Williams <[hidden email]> wrote:
>>>
>>> Hello all,
>>>
>>> I’m in a situation where I need to execute an XPath which contains a variable reference over and over again in a tight loop.  At each iteration in the loop the source document will be different and the variable may contain a different value.  Looking at the JavaDocs it seems I can’t use the XPath.compile to precompile the XPath because of the changing variable value and I therefore need to call evaluate on each iteration.  Is this true? If so, is there a big performance penalty  for doing this? ..and Is there a way around this in Saxon?
>>>
>>> Thank you,
>>>
>>> -jOrGe W.
>>>
>>> ------------------------------------------------------------------------------
>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>>> patterns at an interface-level. Reveals which users, apps, and protocols are
>>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>>> planning reports. http://sdm.link/zohodev2dev
>>> _______________________________________________
>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports. http://sdm.link/zohodev2dev
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Loading...