Try/Catch overhead because of potential multithreading
Under Saxon-EE, when try/catch is executed, the xsl:try code prepares for the eventuality that an xsl:result-document instruction will be executed asynchronously during the xsl:try, in which case the xsl:try cannot complete until the xsl:result-document instruction has successfully completed.
This turns out to impose a signficant overhead (about 50ms on the cost of the xsl:try instruction) which can rapidly accumulate if the try/catch encloses only a small amount of code that is frequently executed.
It appears to be possible to avoid this overhead by having the Saxon
ThreadManagerEE class create the underlying
CompletionService only when they are first needed, that is, when a result-document instruction is actually executed.
#1 Updated by Michael Kay over 2 years ago
- Category set to Multithreading
- Status changed from In Progress to Resolved
- Priority changed from Low to Normal
- Fix Committed on Branch 9.9 added
Actually the 50ms figure isn't for one execution of xsl;try, it is for many executions, but the fact remains that it's a signficant cost (in this use case, about 5% of the overall stylesheet execution cost).
#2 Updated by Michael Kay over 2 years ago
- Status changed from Resolved to In Progress
This change caused a couple of tests to hang, for example result-document-1006.
It no longer hangs if we remove the "synchronized" keywords from
getCompletionService(). However, if these methods aren't synchronized, then it's not clear that they are safe.
Please register to edit this issue