Saxon

Legacy ID: #3533852 Legacy Poster: Michael Kay (mhkay)

Unfortunately, calling methods with side-effects like list.add() makes your code very sensitive to changes in the language optimizer. The best advice would be to try to get rid of them entirely. In practice, that's probably not very realistic since it would mean rewriting your code from scratch. The first issue you are hitting is that Saxon 8.x will not evaluate a local variable until the value is needed (and if it's never needed, it won't evaluate it at all). You can probably fix this by replacing <xsl:variable name="void" select="list:add($MyList,$name)"/> with <xsl:sequence select="list:add($MyList,$name)"/> The second problem is that Saxon now requires that it can identify which method to call using the type information available at compile time. This change was made as a consequence of the much richer type system in XPath 2.0 - the old approach made it too unpredictable which method would be called. You're half-way to solving this by using the "as" attribute to provide the required type information. But you have to get the type right. Either declare the type as "xs:string?" to allow for the possibility of an empty sequence, or change the select to select="string(@name)" to ensure that an empty sequence can't happen. Michael Kay

Legacy ID: #3536638 Legacy Poster: Barry Andrews (titanandrews)

Yes getting rid of these is not going to be very practical. I tried xsl:sequence, but that did not work. I still get a size of zero in the next statement. "Saxon 8.x will not evaluate a local variable until the value is needed (and if it's never needed, it won't evaluate it at all)" I am not sure I understand this. I tried printing the value of $void with xsl:message just to see what would happen and I get the same results. I am using the variable, so according to your statement shouldn't my method be executed. Do you have any more suggestions? On the second problem, using string(@Name) resolves the issue. thank you very much! Barry

Legacy ID: #3536823 Legacy Poster: Michael Kay (mhkay)

I appears you've actually run into a separate problem here, not one of those I described. Some Java classes are handled specially when calling extension functions, and one of these is List (including subclasses like ArrayList). A List treated as representing an XPath sequence, rather than as a single external Java object. So when you call list.add(), the argument that's passed is not your original list, but a newly constructed list to which the members of MyList are added (and there aren't any, so it's empty). After this things get increasingly confusing. The best way around this problem would seem to be to implement a wrapper class MyArrayList which Saxon will treat as an ordinary external object, and apply methods to that rather than to ArrayList. Michael Kay

Legacy ID: #3537135 Legacy Poster: Barry Andrews (titanandrews)

Ah... that's great! That will work. I really appreciate your help. It's nice to see an author so active in answering questions. It is greatly appreciated! I have just one more question if you don't mind. I was doing some initial performance tests comparing 6.5 with 8.6. Basically, I just took the bible.xsl and ran it against ot.xml (Old Testament). It looks like it takes the same amount of time in both versions. (15 secs. for me) I could not find any performance data on the web site. Do you have any such data comparing the 2? Should I expect to see any difference or is it mainly increased functionality in 8.6 and not so much on performance?

Legacy ID: #3537169 Legacy Poster: Michael Kay (mhkay)

There are quite a few new optimizations in 8.6.1, but the bible.xsl stylesheet is a pretty straightforward single pass through the document and that was already quite well optimized in 6.5. Generally speaking, there's a law of diminishing returns with optimization - as time goes on, you optimize cases that occur less and less frequently (or cases that only arise in badly-written code). But they can sometimes be very big improvements. Overall, I'd agree with your observation: for simple stylesheets I think the performance of the two releases is probably quite similar. But I had one user who saw a tenfold improvement by running the same stylesheet under 8.x. Michael Kay

Legacy ID: #3537328 Legacy Poster: Barry Andrews (titanandrews)

After making some changes to our stylesheets I was able to run some performance tests. Now I am seeing the difference in our code which is much more complex than bible.xsl. About 30% increase. I will let you know the final results when we get a little more done on the upgrade. BTW... I thought you might be interested to know that we use XSLT in probably an orthodox way. We use it to take a COBOL XML representation and convert it to a 4GL language. Have you ever heard of such a thing? :)