Stree is an adaptive radix tree implementation used for storing and retrieving literal subjects. It also allows quick matching to wildcard subjects, which is it's major design goal along with using less memory in high subject cardinality situations.
This will be used in the filestore implementation to replace the PSIM hash map which was fast at insert and lookup but suffered when trying to filter based on wildcard subjects.

This is used specifically in calculations on NumPending with a wildcard, and given we push folks to use larger muxed streams with down filtered consumers and/or mirrors this was becoming a performance issue.

Signed-off-by: Derek Collison <derek@nats.io>

Signed-off-by: Derek Collison <derek@nats.io>

Signed-off-by: Derek Collison <derek@nats.io>

Signed-off-by: Derek Collison <derek@nats.io>

Signed-off-by: Neil Twigg <neil@nats.io>

The `_pre` and `cparts` copies are more often than not unnecessary and
result in potentially gigabytes of allocations which can slow down
functions like `NumPending`.

Passing `pre` and `nparts` down recursively without copies is usually
safe, even where there are appends in those, because there is no
concurrency and those appends will not modify the slice length back at
the callsite. Instead we'll only reallocate either when `append` does so
naturally (we've ran out of capacity) or when we know specifically that
we're modifying something in-place (like in `matchParts`).

This improves performance of things like `NumPending` with high subject
cardinality.

Signed-off-by: Neil Twigg <neil@nats.io>

When using `make(x, y, z)`, there is a heap escape due to the non-constant
size/capacity. Try to stay on the stack instead, reducing GC pressure.

Signed-off-by: Neil Twigg <neil@nats.io>

When using `make(x, y, z)`, there is a heap escape due to the
non-constant size/capacity. Try to stay on the stack instead, reducing
GC pressure.

Signed-off-by: Neil Twigg <neil@nats.io>

In #4974 I removed preallocated buffers for `pre` as the copies were
unnecessary on each single recursion, however it turns out that having
a preallocation up front removes quite a few unnecessary allocations
from subject construction, relieving further pressure on the GC.

Signed-off-by: Neil Twigg <neil@nats.io>

In #4974 I removed preallocated buffers for `pre` as the copies were
unnecessary on each single recursion, however it turns out that having a
preallocation up front removes quite a few unnecessary allocations from
subject construction as the underlying memory gets reused throughout the
iteration or match process, relieving further pressure on the GC.

Signed-off-by: Neil Twigg <neil@nats.io>

Signed-off-by: Neil Twigg <neil@nats.io>

…ing memory for the GC.

The solution was to have a node return its children as a []node. Since node256 is sparse the upper layers need to check for nil, but this improved the performance.

Signed-off-by: Derek Collison <derek@nats.io>