Project

Profile

Help

Bug #4074

Try/Catch overhead because of potential multithreading

Added by Michael Kay over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Multithreading
Sprint/Milestone:
-
Start date:
2018-12-19
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.9
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.

History

#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

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.

#3 Updated by Michael Kay over 2 years ago

  • 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.

#4 Updated by O'Neil Delpratt over 2 years ago

  • % 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.

#5 Updated by O'Neil Delpratt over 2 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF