Quantcast

Big performance differences between EE/PE versions on .NET

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

Big performance differences between EE/PE versions on .NET

Jirka Kosek
Hi,

I'm trying to speed up a complex transformation. Since I have exhausted
probably all possibilities to speed up XSLT code itself -- using keys
where possible, not using expensive axes like descendant, preceding,
following, ... I'm now focused on using different editions of Saxon.

In production environment transformation is run inside .NET application.
I tried to benchmark differences between PE/EE/EE without optimizations
and raw times are:

PE: compilation: 2s execution: 24s
EE: compilation: 8s execution: 44s
EE (without optimizations -opt:0): compilation: 2s execution: 53s

I'm quite surprised that EE is so slower in execution. Is there any
reason for this? Could this be something specific to .NET platform?

I'm asking because XSLT development is done with Java version of Saxon.
Numbers are completely different here:

PE: compilation: 1.5s execution: 10s
EE: compilation: 3s   execution: 11s

So execution times are similar -- which is no surprise as code is quite
optimized itself. Also I though that .NET will be slower by few tens of
percents but being slow 2-5 times was really shocking observation.

We are using 9.6.0.9 version of product. Unfortunately I can't share
source code (and it's nasty anyway), but I'm looking mostly for some
generic advices about things which are inherently know to be slow and
problematic in .NET version of Saxon.

Transformation is actually pipeline of 30 individual transformations --
results are passed using variables between invocation of individual
transformation steps. Most steps are identity transforms doing few
additional manipulations, usually quite cheep ones.

Thanks,

                                        Jirka

--
------------------------------------------------------------------
  Jirka Kosek      e-mail: [hidden email]      http://xmlguru.cz
------------------------------------------------------------------
     Professional XML and Web consulting and training services
DocBook/DITA customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
------------------------------------------------------------------
    Bringing you XML Prague conference    http://xmlprague.cz
------------------------------------------------------------------


------------------------------------------------------------------------------

_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 

signature.asc (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Big performance differences between EE/PE versions on .NET

Campbell, Lance
Are you transforming against templates so you can do the transformations against precompiled byte code?  If not I would try that.  It is much faster.  My understanding was the EE was optimized for those types of transformations.  But I could be wrong.

Lance Campbell
University of Illinois

-----Original Message-----
From: Jirka Kosek [mailto:[hidden email]]
Sent: Wednesday, November 23, 2016 11:40 AM
To: Mailing list for SAXON XSLT queries <[hidden email]>
Subject: [saxon] Big performance differences between EE/PE versions on .NET

Hi,

I'm trying to speed up a complex transformation. Since I have exhausted probably all possibilities to speed up XSLT code itself -- using keys where possible, not using expensive axes like descendant, preceding, following, ... I'm now focused on using different editions of Saxon.

In production environment transformation is run inside .NET application.
I tried to benchmark differences between PE/EE/EE without optimizations and raw times are:

PE: compilation: 2s execution: 24s
EE: compilation: 8s execution: 44s
EE (without optimizations -opt:0): compilation: 2s execution: 53s

I'm quite surprised that EE is so slower in execution. Is there any reason for this? Could this be something specific to .NET platform?

I'm asking because XSLT development is done with Java version of Saxon.
Numbers are completely different here:

PE: compilation: 1.5s execution: 10s
EE: compilation: 3s   execution: 11s

So execution times are similar -- which is no surprise as code is quite optimized itself. Also I though that .NET will be slower by few tens of percents but being slow 2-5 times was really shocking observation.

We are using 9.6.0.9 version of product. Unfortunately I can't share source code (and it's nasty anyway), but I'm looking mostly for some generic advices about things which are inherently know to be slow and problematic in .NET version of Saxon.

Transformation is actually pipeline of 30 individual transformations -- results are passed using variables between invocation of individual transformation steps. Most steps are identity transforms doing few additional manipulations, usually quite cheep ones.

Thanks,

                                        Jirka

--
------------------------------------------------------------------
  Jirka Kosek      e-mail: [hidden email]      http://xmlguru.cz
------------------------------------------------------------------
     Professional XML and Web consulting and training services DocBook/DITA customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
------------------------------------------------------------------
    Bringing you XML Prague conference    http://xmlprague.cz
------------------------------------------------------------------

------------------------------------------------------------------------------
_______________________________________________
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: Big performance differences between EE/PE versions on .NET

Michael Kay
In reply to this post by Jirka Kosek
When we first brought out the .NET product, it was about 30% slower than Java. More recently we have often seen figures showing it 3 to 5 times slower, and despite considerable effort, we have failed to identify why this should be the case. We know that we are executing exactly the same source code instructions within Saxon in the two cases, or at least that the paths are sufficiently close that they don't account for the difference. One possibility is that the JDK (or its class library) has simply become faster (especially with JIT/hotspot compilation), and the speed improvements have not been matched when the code is translated to IL code. We've investigated whether it might have something to do with the move (by IKVMC) from the GNU ClassPath to the OpenJDK libraries, but we couldn't find any evidence supporting this hypothesis. The ratio is not consistent, but the figures you are reporting match our own experience.

In fact one of the frustrations in getting to the bottom of this is that it can be very hard to get reproducible measurements. Sometimes you'll take a set of measurements one day, and the next day they come out quite different. It's almost as if the operating system is making random decisions about what priority to allocate to the program under test.

We do know that bytecode generation (which is on by default in EE) is a lot more expensive under .NET than in the Java product, and performance can often be improved in .NET by switching it off. This is especially true, of course, if you are compiling the stylesheet once in order to execute it once; it's also true when you have very large stylesheets with lots of template rules that are rarely executed (DocBook is a classic example). The problems with bytecode generation are often more to do with memory than with CPU cycles; the generated classes can occupy a lot of space, and (I believe) loaded classes are not eligible for garbage collection under .NET, which can increase memory pressure elsewhere in the system. So I'd suggest taking your measurements again with FeatureKeys.GENERATE_BYTECODE set to false. (-opt:0 also has this effect, but it may be suppressing optimisations that are really useful as well.)

On the same platform, EE should in theory always be faster at run-time than PE or HE on the same code, though it may take a little longer at compile time. If that isn't the case, then it's something we want to investigate (of course the optimizer has to make guesses and sometimes it can guess wrong, but we can only tweak it if we observe the anomalies.)

Over the last year or so we've identified a number of cases where compilation times have regressed since (say) 9.1, and there are a number of fixes in the 9.7 branch relating to this - in most cases this is for fairly pathological code, e.g. with hundreds of local variables declared within a single template. But we've become generally aware that compilation time needs to be addressed and this is a current focus for the next release.

Hope this helps...

Michael Kay
Saxonica

> On 23 Nov 2016, at 17:40, Jirka Kosek <[hidden email]> wrote:
>
> Hi,
>
> I'm trying to speed up a complex transformation. Since I have exhausted
> probably all possibilities to speed up XSLT code itself -- using keys
> where possible, not using expensive axes like descendant, preceding,
> following, ... I'm now focused on using different editions of Saxon.
>
> In production environment transformation is run inside .NET application.
> I tried to benchmark differences between PE/EE/EE without optimizations
> and raw times are:
>
> PE: compilation: 2s execution: 24s
> EE: compilation: 8s execution: 44s
> EE (without optimizations -opt:0): compilation: 2s execution: 53s
>
> I'm quite surprised that EE is so slower in execution. Is there any
> reason for this? Could this be something specific to .NET platform?
>
> I'm asking because XSLT development is done with Java version of Saxon.
> Numbers are completely different here:
>
> PE: compilation: 1.5s execution: 10s
> EE: compilation: 3s   execution: 11s
>
> So execution times are similar -- which is no surprise as code is quite
> optimized itself. Also I though that .NET will be slower by few tens of
> percents but being slow 2-5 times was really shocking observation.
>
> We are using 9.6.0.9 version of product. Unfortunately I can't share
> source code (and it's nasty anyway), but I'm looking mostly for some
> generic advices about things which are inherently know to be slow and
> problematic in .NET version of Saxon.
>
> Transformation is actually pipeline of 30 individual transformations --
> results are passed using variables between invocation of individual
> transformation steps. Most steps are identity transforms doing few
> additional manipulations, usually quite cheep ones.
>
> Thanks,
>
> Jirka
>
> --
> ------------------------------------------------------------------
>  Jirka Kosek      e-mail: [hidden email]      http://xmlguru.cz
> ------------------------------------------------------------------
>     Professional XML and Web consulting and training services
> DocBook/DITA customization, custom XSLT/XSL-FO document processing
> ------------------------------------------------------------------
> OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
> ------------------------------------------------------------------
>    Bringing you XML Prague conference    http://xmlprague.cz
> ------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help


------------------------------------------------------------------------------
_______________________________________________
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: Big performance differences between EE/PE versions on .NET

Dimitre Novatchev
Some people have shared their experience (for non-saxon products) that
IKVM can be significantly slower than using a commercial solution,
such as JNBridge:

From: http://droolstonet.blogspot.com/


<quote>
 Building the knowledge base and your rules is an expensive operation
that usually takes seconds. With IKVM it took 21 sec to build a drool
file with 1,000 rules
 whereas JNBridge only took 9 secs.
</quote>


In the same resource, there is extensive advice how to port a Java
application to .NET using IKVM.


The commercial solution mentioned above:
JNBridge:  http://jnbridge.com/

Purchase price from $260.  :(


Cheers,
Dimitre

On Wed, Nov 23, 2016 at 10:42 AM, Michael Kay <[hidden email]> wrote:

> When we first brought out the .NET product, it was about 30% slower than Java. More recently we have often seen figures showing it 3 to 5 times slower, and despite considerable effort, we have failed to identify why this should be the case. We know that we are executing exactly the same source code instructions within Saxon in the two cases, or at least that the paths are sufficiently close that they don't account for the difference. One possibility is that the JDK (or its class library) has simply become faster (especially with JIT/hotspot compilation), and the speed improvements have not been matched when the code is translated to IL code. We've investigated whether it might have something to do with the move (by IKVMC) from the GNU ClassPath to the OpenJDK libraries, but we couldn't find any evidence supporting this hypothesis. The ratio is not consistent, but the figures you are reporting match our own experience.
>
> In fact one of the frustrations in getting to the bottom of this is that it can be very hard to get reproducible measurements. Sometimes you'll take a set of measurements one day, and the next day they come out quite different. It's almost as if the operating system is making random decisions about what priority to allocate to the program under test.
>
> We do know that bytecode generation (which is on by default in EE) is a lot more expensive under .NET than in the Java product, and performance can often be improved in .NET by switching it off. This is especially true, of course, if you are compiling the stylesheet once in order to execute it once; it's also true when you have very large stylesheets with lots of template rules that are rarely executed (DocBook is a classic example). The problems with bytecode generation are often more to do with memory than with CPU cycles; the generated classes can occupy a lot of space, and (I believe) loaded classes are not eligible for garbage collection under .NET, which can increase memory pressure elsewhere in the system. So I'd suggest taking your measurements again with FeatureKeys.GENERATE_BYTECODE set to false. (-opt:0 also has this effect, but it may be suppressing optimisations that are really useful as well.)
>
> On the same platform, EE should in theory always be faster at run-time than PE or HE on the same code, though it may take a little longer at compile time. If that isn't the case, then it's something we want to investigate (of course the optimizer has to make guesses and sometimes it can guess wrong, but we can only tweak it if we observe the anomalies.)
>
> Over the last year or so we've identified a number of cases where compilation times have regressed since (say) 9.1, and there are a number of fixes in the 9.7 branch relating to this - in most cases this is for fairly pathological code, e.g. with hundreds of local variables declared within a single template. But we've become generally aware that compilation time needs to be addressed and this is a current focus for the next release.
>
> Hope this helps...
>
> Michael Kay
> Saxonica
>
>> On 23 Nov 2016, at 17:40, Jirka Kosek <[hidden email]> wrote:
>>
>> Hi,
>>
>> I'm trying to speed up a complex transformation. Since I have exhausted
>> probably all possibilities to speed up XSLT code itself -- using keys
>> where possible, not using expensive axes like descendant, preceding,
>> following, ... I'm now focused on using different editions of Saxon.
>>
>> In production environment transformation is run inside .NET application.
>> I tried to benchmark differences between PE/EE/EE without optimizations
>> and raw times are:
>>
>> PE: compilation: 2s execution: 24s
>> EE: compilation: 8s execution: 44s
>> EE (without optimizations -opt:0): compilation: 2s execution: 53s
>>
>> I'm quite surprised that EE is so slower in execution. Is there any
>> reason for this? Could this be something specific to .NET platform?
>>
>> I'm asking because XSLT development is done with Java version of Saxon.
>> Numbers are completely different here:
>>
>> PE: compilation: 1.5s execution: 10s
>> EE: compilation: 3s   execution: 11s
>>
>> So execution times are similar -- which is no surprise as code is quite
>> optimized itself. Also I though that .NET will be slower by few tens of
>> percents but being slow 2-5 times was really shocking observation.
>>
>> We are using 9.6.0.9 version of product. Unfortunately I can't share
>> source code (and it's nasty anyway), but I'm looking mostly for some
>> generic advices about things which are inherently know to be slow and
>> problematic in .NET version of Saxon.
>>
>> Transformation is actually pipeline of 30 individual transformations --
>> results are passed using variables between invocation of individual
>> transformation steps. Most steps are identity transforms doing few
>> additional manipulations, usually quite cheep ones.
>>
>> Thanks,
>>
>>                                       Jirka
>>
>> --
>> ------------------------------------------------------------------
>>  Jirka Kosek      e-mail: [hidden email]      http://xmlguru.cz
>> ------------------------------------------------------------------
>>     Professional XML and Web consulting and training services
>> DocBook/DITA customization, custom XSLT/XSL-FO document processing
>> ------------------------------------------------------------------
>> OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
>> ------------------------------------------------------------------
>>    Bringing you XML Prague conference    http://xmlprague.cz
>> ------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help



--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
To achieve the impossible dream, try going to sleep.
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
Sanity is madness put to good use.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.

------------------------------------------------------------------------------
_______________________________________________
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: Big performance differences between EE/PE versions on .NET

Jirka Kosek
In reply to this post by Michael Kay
On 23.11.2016 19:42, Michael Kay wrote:

Hi Mike, thanks for very detailed response, few comments are below inline:

> When we first brought out the .NET product, it was about 30% slower
> than Java. More recently we have often seen figures showing it 3 to 5
> times slower, and despite considerable effort, we have failed to
> identify why this should be the case.

At least this confirms our numbers, so I know its feature and not bug on
our side :-)

> We do know that bytecode generation (which is on by default in EE) is
> a lot more expensive under .NET than in the Java product, and
> performance can often be improved in .NET by switching it off. This
> is especially true, of course, if you are compiling the stylesheet
> once in order to execute it once; it's also true when you have very
> large stylesheets with lots of template rules that are rarely
> executed (DocBook is a classic example). The problems with bytecode
> generation are often more to do with memory than with CPU cycles; the
> generated classes can occupy a lot of space, and (I believe) loaded
> classes are not eligible for garbage collection under .NET, which can
> increase memory pressure elsewhere in the system. So I'd suggest
> taking your measurements again with FeatureKeys.GENERATE_BYTECODE set
> to false. (-opt:0 also has this effect, but it may be suppressing
> optimisations that are really useful as well.)
I have tried disabling byte code generation but effect looks identical
to -opt:0 -- execution times were same both for -opt:0 and with disabled
byte code generation.

> On the same platform, EE should in theory always be faster at
> run-time than PE or HE on the same code, though it may take a little
> longer at compile time. If that isn't the case, then it's something
> we want to investigate (of course the optimizer has to make guesses
> and sometimes it can guess wrong, but we can only tweak it if we
> observe the anomalies.)

On my transformation on .NET EE execution was twice time slower then PE.
I have recommended developer team to switch to PE for time being. I can
send you transformation and obfuscated data offlist if you are
interested. Same transformation on Java produced very similar execution
times for both PE and EE, both being ~20% faster then HE. So it could be
that EE optimizer produced some code which is expensive to execute on .NET.

> Over the last year or so we've identified a number of cases where
> compilation times have regressed since (say) 9.1, and there are a
> number of fixes in the 9.7 branch relating to this - in most cases
> this is for fairly pathological code, e.g. with hundreds of local
> variables declared within a single template. But we've become
> generally aware that compilation time needs to be addressed and this
> is a current focus for the next release.

For this particular transformation execution in 9.1 is ~15% faster then
on 9.6PE/EE and 30% faster then 9.7HE. I haven't tested on 9.7PE/EE though.

Many thanks,

                                        Jirka


--
------------------------------------------------------------------
  Jirka Kosek      e-mail: [hidden email]      http://xmlguru.cz
------------------------------------------------------------------
     Professional XML and Web consulting and training services
DocBook/DITA customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
------------------------------------------------------------------
    Bringing you XML Prague conference    http://xmlprague.cz
------------------------------------------------------------------


------------------------------------------------------------------------------

_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 

signature.asc (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Big performance differences between EE/PE versions on .NET

Michael Kay
I would certainly be interested in exploring this test case in more detail.

Michael Kay
Saxonica

> On 28 Nov 2016, at 10:46, Jirka Kosek <[hidden email]> wrote:
>
> On 23.11.2016 19:42, Michael Kay wrote:
>
> Hi Mike, thanks for very detailed response, few comments are below inline:
>
>> When we first brought out the .NET product, it was about 30% slower
>> than Java. More recently we have often seen figures showing it 3 to 5
>> times slower, and despite considerable effort, we have failed to
>> identify why this should be the case.
>
> At least this confirms our numbers, so I know its feature and not bug on
> our side :-)
>
>> We do know that bytecode generation (which is on by default in EE) is
>> a lot more expensive under .NET than in the Java product, and
>> performance can often be improved in .NET by switching it off. This
>> is especially true, of course, if you are compiling the stylesheet
>> once in order to execute it once; it's also true when you have very
>> large stylesheets with lots of template rules that are rarely
>> executed (DocBook is a classic example). The problems with bytecode
>> generation are often more to do with memory than with CPU cycles; the
>> generated classes can occupy a lot of space, and (I believe) loaded
>> classes are not eligible for garbage collection under .NET, which can
>> increase memory pressure elsewhere in the system. So I'd suggest
>> taking your measurements again with FeatureKeys.GENERATE_BYTECODE set
>> to false. (-opt:0 also has this effect, but it may be suppressing
>> optimisations that are really useful as well.)
>
> I have tried disabling byte code generation but effect looks identical
> to -opt:0 -- execution times were same both for -opt:0 and with disabled
> byte code generation.
>
>> On the same platform, EE should in theory always be faster at
>> run-time than PE or HE on the same code, though it may take a little
>> longer at compile time. If that isn't the case, then it's something
>> we want to investigate (of course the optimizer has to make guesses
>> and sometimes it can guess wrong, but we can only tweak it if we
>> observe the anomalies.)
>
> On my transformation on .NET EE execution was twice time slower then PE.
> I have recommended developer team to switch to PE for time being. I can
> send you transformation and obfuscated data offlist if you are
> interested. Same transformation on Java produced very similar execution
> times for both PE and EE, both being ~20% faster then HE. So it could be
> that EE optimizer produced some code which is expensive to execute on .NET.
>
>> Over the last year or so we've identified a number of cases where
>> compilation times have regressed since (say) 9.1, and there are a
>> number of fixes in the 9.7 branch relating to this - in most cases
>> this is for fairly pathological code, e.g. with hundreds of local
>> variables declared within a single template. But we've become
>> generally aware that compilation time needs to be addressed and this
>> is a current focus for the next release.
>
> For this particular transformation execution in 9.1 is ~15% faster then
> on 9.6PE/EE and 30% faster then 9.7HE. I haven't tested on 9.7PE/EE though.
>
> Many thanks,
>
> Jirka
>
>
> --
> ------------------------------------------------------------------
>  Jirka Kosek      e-mail: [hidden email]      http://xmlguru.cz
> ------------------------------------------------------------------
>     Professional XML and Web consulting and training services
> DocBook/DITA customization, custom XSLT/XSL-FO document processing
> ------------------------------------------------------------------
> OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
> ------------------------------------------------------------------
>    Bringing you XML Prague conference    http://xmlprague.cz
> ------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help


------------------------------------------------------------------------------
_______________________________________________
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: Big performance differences between EE/PE versions on .NET

Michael Kay
We have reproduced these measurements and have logged an issue at

https://saxonica.plan.io/issues/3052

Please track that bug entry for progress reports.

Michael Kay
Saxonica


> On 28 Nov 2016, at 22:26, Jirka Kosek <[hidden email]> wrote:
>
> On Mon, Nov 28, 2016, at 12:14, Michael Kay wrote:
>> I would certainly be interested in exploring this test case in more
>> detail.
>
> Hi Mike,
>
> I have attached transformation (expanded-transform.xsl) and obfuscated
> data (input.xml). 3rd file is auxiliary input read by transformation.
> Please keep these files private.
>


------------------------------------------------------------------------------
_______________________________________________
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: Big performance differences between EE/PE versions on .NET

Michael Kay
O'Neil has discovered that we built Saxon-EE on .NET incorrectly with debug enabled, and fixing this solves the performance anomaly.

We've learnt a few other things as well in the course of the investigation, including discovering some new tools for instrumentation on .NET.

Michael Kay
Saxonica

> On 30 Nov 2016, at 15:59, Michael Kay <[hidden email]> wrote:
>
> We have reproduced these measurements and have logged an issue at
>
> https://saxonica.plan.io/issues/3052
>
> Please track that bug entry for progress reports.
>
> Michael Kay
> Saxonica
>
>
>> On 28 Nov 2016, at 22:26, Jirka Kosek <[hidden email]> wrote:
>>
>> On Mon, Nov 28, 2016, at 12:14, Michael Kay wrote:
>>> I would certainly be interested in exploring this test case in more
>>> detail.
>>
>> Hi Mike,
>>
>> I have attached transformation (expanded-transform.xsl) and obfuscated
>> data (input.xml). 3rd file is auxiliary input read by transformation.
>> Please keep these files private.
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 


------------------------------------------------------------------------------
_______________________________________________
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: Big performance differences between EE/PE versions on .NET

Jirka Kosek
On 1.12.2016 22:14, Michael Kay wrote:
> O'Neil has discovered that we built Saxon-EE on .NET incorrectly with debug enabled, and fixing this solves the performance anomaly.

Hi,

thanks for looking into this. Is there any chance that you will provide
new build for 9.6, or will this fix be available only in 9.7?

                                Jirka


--
------------------------------------------------------------------
  Jirka Kosek      e-mail: [hidden email]      http://xmlguru.cz
------------------------------------------------------------------
     Professional XML and Web consulting and training services
DocBook/DITA customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
------------------------------------------------------------------
    Bringing you XML Prague conference    http://xmlprague.cz
------------------------------------------------------------------


------------------------------------------------------------------------------

_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 

signature.asc (203 bytes) Download Attachment
Loading...