Thanks for the feedback, David. This is the kind of thing we can only discover by experience.

We current set the number of threads to Runtime.getRuntime().availableProcessors()

It would be interesting to know what this returns on your system. I guess we could cap this at some limit, or we could provide a configuration option to set the value, or perhaps a parameter to the collation URI.

You can disable the feature entirely by setting the configuration property FeatureKeys.ALLOW_MULTITHREADING to false, or by supplying your own CollectionURIResolver.

Michael Kay


> Mike,
> I am currently using the following method for reading files from a
> directory of unknown contents:
> <xsl:for-each select="for $d in collection(...) return
> saxon:discard-document($d)">
> ....
> </xsl:for-each>
> I noticed today instances where it appear saxon was over-ambitious in
> terms
> of determining how many threads to use when executing this. It attempted
> to
> open/parse too many documents at once. In one case this caused a large
> performance hit (~85% reduction in speed). In another case I ran out of
> heap space.
> Are there any ways (either explicitly or implicitly) to control/limit the
> number of threads used at a time?
> -David
> --
> "A false conclusion, once arrived at and widely accepted is not dislodged
> easily, and the less it is understood, the more tenaciously it is held." -
> Cantor's Law of Preservation of Ignorance.
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> saxon-help mailing list archived at