perf: allocate template caches lazily - #307
Merged
mikemiles-dev merged 1 commit intoJul 21, 2026
Merged
Conversation
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Each parser owns two NetFlow v9 and four IPFIX template LRU caches.
LruCache::new(capacity)immediately reserves the configured hash-map capacity, so a newly admitted source reserves storage for all six caches before receiving any template.With the default capacity of 1,000, constructing one parser requested 209,760 bytes and retained 209,680 bytes solely for mostly empty cache state. This becomes significant for multi-source collectors that keep one parser per exporter/domain.
Change
LazyLruCachewrapper for the six template caches.The wrapper preserves the existing capacity, LRU order, eviction behavior, TTL handling, withdrawals, metrics, persistence, public APIs, and parser debug representation. Source-routing and pending-flow LRUs are unchanged.
Measured results
Parser construction now requests 192 bytes and retains 112 bytes. With a configured capacity of 100,000, inserting the first template requests 848 bytes while still reporting the configured maximum and one live entry.
For 10,000 NetFlow v9 sources with one one-field template each:
Eleven alternating paired trials across direct and source-scoped NetFlow v9/IPFIX parse and iterator paths retained at least 98.336% of baseline hot-path throughput. Hot allocation counts and requested bytes were identical. Creating and parsing the first template for 1,000 new v9 sources was 2.01 times faster, while requested allocation fell from 211,732,084 to 2,392,084 bytes.
Verification
./scripts/check-all.sh--no-default-featurestest suite