Saxon

Thanks: we're very reliant on users to tell us where bottlenecks occur in real production workloads.

I'm wondering whether this pool mechanism actually adds value at all. Object creation in Java is much less of an overhead than it used to be.

If calls on SequenceType.makeSequenceType() are so common as to cause a bottleneck, it would be nice to know where these calls are coming from, because perhaps there are other measures that would be more effective. At a first glance nearly all the calls on the method are during stylesheet/query compilation which we have usually assumed is less performance-critical than run-time execution, though we're starting to take it much more seriously.

We're only actually using the pool for built-in atomic types, and I'm inclined to replace this mechanism by giving each BuiltInAtomicType a set of four fields containing the SequenceType's one, oneOrMore, zeroOrMore, zeroOrOne, with corresponding memo-getters. These don't need to be synchronized, or at worst they would be synchronized on the BuiltInAtomicType object. In fact we could put these getter methods on ItemType. In the vast majority of cases when we call SequenceType.makeSequenceType() we know the atomic type statically, so this must be better than a hash table lookup.

I have implemented this change on the 9.8 branch (that is, the pool of SequenceTypes for BuiltInAtomicTypes is abolished, and replaced with four lazily-evaluated fields in the BuiltInAtomicType object).

Great, thanks! Where can I find information about when the next maintenance release of 9.7 will be?

Sorry, we don't announce (or plan!) maintenance releases more than a few days in advance. We produce them when there's a critical bug with no workaround, or when the level of bugs gets to a point where a release is worthwhile, or when it's a few months since the last one.

I'll keep watch for next release then. Thanks!

William and I were looking for the fix in 9.7.0-19 but don't see it, at least not the change we expected. SequenceType.pool is still using Collections.synchronizedMap(). After profiling we still see the same performance bottleneck here in SequenceType.