NamePool changes

The NamePool is no longer used for names such as variable names which are not used at run-time. This change is made to ease pressure on the NamePool as a shared resource which can become a bottleneck for some high-throughput applications, and which can gradually fill for long-running applications. The problem can arise particularly because the Saxon optimizer generates variable names at random for internal variables, meaning that there is a slow but steady increase in the number of entries in the NamePool even under a very stable workload. The name of a variable is now held internally in a StructuredQName object, which holds the prefix, URI, and local name in a structure that is designed for economy in space usage combined with an efficient equals() test.

The same change has been made for other kinds of name such as function names, template names, attribute set names, character map names, mode names, output format names, decimal format names, and key names. In the vast majority of cases these names are resolved at compile time so there was little benefit from using the shared name pool.

Local parameters to XSLT templates, which are matched by name at run-time, still use numeric identifiers for efficient matching, but these are no longer fingerprints allocated from the namepool, they are numbers allocated by the stylesheet compiler locally to a stylesheet.

User applications are unlikely to be affected by the change unless they probe rather deeply into Saxon system-programming interfaces, for example interfaces provided for debuggers, or for defining your own extension function binding factories. But if you provide your own implementation of the StaticContext interface, you will need to change the method bindVariable() to accept a StructuredQName rather than an integer fingerprint.