Bug #4074
closed
Try/Catch overhead because of potential multithreading
Fix Committed on Branch:
9.9
Fixed in Maintenance Release:
Description
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 ExecutorService
and CompletionService
only when they are first needed, that is, when a result-document instruction is actually executed.
- 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).
- Status changed from Resolved to In Progress
Reopening.
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 ThreadManagerEE.getExecutorService()
and getCompletionService()
. However, if these methods aren't synchronized, then it's not clear that they are safe.
- Status changed from In Progress to Resolved
Fixed by synchronizing at the level of the activate()
method instead -- though it's not entirely clear why this makes a difference.
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.1.1 added
Bug fix applied to the Saxon 9.9.1.1 maintenance release.
- Status changed from Resolved to Closed
Please register to edit this issue
Also available in: Atom
PDF