Saxonica Developer Community

2019-03-21

• 
  Michael Kay Saxon

  17:26 · Closed issue

  Fixed as described. Bug #3958 (Resolved): Scheduling algorithm for xsl:for-each/@saxon:threads=N

  The scheduling algorithm used by `xsl:for-each/@saxon:threads="N"` is not especially smart. In particular, it gives poor throughput when the amount of work required to process different items in the input sequence is highly variable. The...
• 
  Michael Kay We can get the elapsed time for this task down to a little over 10 seconds simply by increasing the number of items we place on the queue when priming it. Currently if the number of threads is 4, then we put the first 4 items on the queu...

  17:19 · Commented on issue
• 
  Michael Kay I can't help feeling that the answer to this must lie in using the Streams machinery, and Spliterators in particular. I've spent another hour or so reading all about Spliterators, and I have to confess I really don't understand the parad...

  16:18 · Commented on issue
• 
  Michael Kay Looking more carefully at the logic of the MultithreadedContextMappingIterator, it's clear that this has nothing to do with the nature of the ExecutorPool and depends entirely on the structure of the BlockingQueue that we maintain. We pr...

  14:04 · Commented on issue
• 
  Michael Kay Thanks. What platform are you running on?
  

  12:37 · Commented on issue

2019-03-20

• 
  Michael Kay Saxon

  00:18 · Edited issue

  I have not been able to reproduce the 30second run-time; the test is taking just over 10 seconds, and this is true whether I use `newFixedThreadPool()` or `newWorkStealingPool()`. As a result, I don't think it is appropriate to make any ... Bug #3958 (In Progress): Scheduling algorithm for xsl:for-each/@saxon:threads=N

  The scheduling algorithm used by `xsl:for-each/@saxon:threads="N"` is not especially smart. In particular, it gives poor throughput when the amount of work required to process different items in the input sequence is highly variable. The...
• 
  Michael Kay Saxon

  22:51 · Closed issue

  Fixed on 9.9 and trunk. The changes were surprisingly extensive, as they involved keeping more detailed information on a component about how its visibility was computed (new class VisibilityProvenance). Bug #4155 (Resolved): <xsl:expose component="mode"> has no effect on implicitly-declared modes

  Although it's not 100% clear in the spec, on balance I think `xsl:expose` should be capable of setting the visibility of a mode that is defined "by reference" rather than through an explicit xsl:mode declaration.
  It's actually having ...
• 
  Michael Kay Made further changes: instead of simply recording whether the visibility of a component is explicit or implicit, we now capture the provenance of the visibility property as one of implicit, declared, exposed, accepted, derived. This is n...

  17:33 · Commented on issue
• 
  Michael Kay Saxon

  11:35 · Closed issue

  Patch committed on 9.9 and trunk. Unit test TestXdmNode.testToString() added. Bug #4173 (Resolved): XdmNode.toString() on text nodes

  Bug #4081 -- see comment 5 -- changed the effect of XdmNode.toString() to trim leading and trailing whitespace from the result. This is fine for document and element nodes, but it is wrong for text nodes.
  Note that XdmNode.toString() ...
• 
  Michael Kay Looking at the code I noticed that the escaping for attribute and namespace nodes is done incorrectly. The code is written
  ~~~
  String val = node.getStringValue()
  .replace("\"", "&quot;")
  .rep...

  10:40 · Commented on issue