As examined in YANGTOOLS-1159, YANGTOOLS-1204 and other places, we spend a significant amount of time traversing the NamespaceStorageNode tree towards root in order to find things that are shared either on source-local, module-local or global scope.

At the end of the day, for any ParserNamespace operation, we have to find its NamespaceBehaviour and then execute the request using that behaviour.

There is a connection between these operations, at least in the yang-parser-reactor implementation. The story goes something like this:

1. there are 4 StorageNodeTypes
2. we have a single baseline NamespaceStorageNode implementation (NamespaceStorageSupport), which is subclassed
3. there is the notion of NamespaceBehaviour.Registry, of which we have three implementations:
   1. BuildGlobalContext, which also is the only StorageNodeType.GLOBAL
   2. SourceSpecificContext, which also is the only StorageNodeType.SOURCE_LOCAL_SPECIAL
   3. StatementSupportBundle, which seems to be quite unrelated to this problem, but has interaction with BuildGlobalContext
4. StorageNodeType.ROOT_STATEMENT_LOCAL is only implemented by RootStatementContext
5. StorageNodeType.STATEMENT_LOCAL by all other ReactorStmtCtx subclasses

The behaviour count breaks down as follows:

1. global() has 19 references (GLOBAL node)
2. sourceLocal() has 6 references (SOURCE_LOCAL_SPECIAL node)
3. statementLocal() has 7 references (STATEMENT_LOCAL node)
4. rootStatementLocal() has 3 references (ROOT_STATEMENT_LOCAL node)
5. treeScoped() has 2 references (which means the first match node along ancestor axis)

The yang-parser-reactor implementation essentially requires a walk to BuildGlobalContext to acquire NamespaceBehaviours, which it wraps with extended implementations (Simple/VirtualNamespaceContext) – hence these implementations are primed to have a quick way to access the GLOBAL node. Furthermore RootStatementContext has a direct pointer to SourceSpecificContext and that has a direct pointer to BuildGlobalContext.

Based on these implementation specifics, there seems to be an opportunity to knock off at least the global() case in that we would memoize BuildGlobalContext reference in NamespaceContexts – and then we just need to provide a mechanism for them to provide access to it to their respective NamespaceBehaviours.

This will provide immediate benefits to major users:

1. SUPPORTED_FEATURES, which is behind ReactorStmtCtx.isSupportedByFeatures()
2. FEATURE, which does the the same
3. MODULECTX_TO_QNAME, which participates on local QName construction

as these will not have to walk the statement tree again to reach BuildGlobalContext.

While there may be other opportunities, this issue should focus on:

1. disconnecting StatementSupportBundle and NamespaceBehaviour.Registry
2. perhaps making NamespaceBehaviour.Registry a yang-parser-reactor-internal thing
3. providing a way for NamespaceBehaviour.global() to receive BuildGlobalContext reference without traversing NamespaceStorageNode tree