Switch to WeakMap and String objects to avoid memory leak. Fixes #20 and #34.#43
Closed
johannesodland wants to merge 1 commit intodevelopit:masterfrom
Closed
Switch to WeakMap and String objects to avoid memory leak. Fixes #20 and #34.#43johannesodland wants to merge 1 commit intodevelopit:masterfrom
johannesodland wants to merge 1 commit intodevelopit:masterfrom
Conversation
TimDaub
added a commit
to attestate/vhtml-memory-safe
that referenced
this pull request
Oct 21, 2025
Problem:
- Original code used `let sanitized = {}` which never garbage collects
- This causes unbounded memory growth in SSR scenarios
- Heap analysis showed ~5,400 concatenated strings per feed generation
Solution:
- Replace plain object with LRUCache from lru-cache package
- Cap at 10,000 entries (~2 feed generations worth)
- Count-based eviction with 5 MB safety cap
- Maintains string primitives (no String object overhead like WeakMap approach)
Based on heap analysis:
- ~21,500 strings/minute growth rate
- ~5,400 strings per feed (15s regeneration cycle)
- Average string size: ~32 bytes
- 10,000 entries = ~320 KB stable memory footprint
Related: developit#20, developit#34, developit#43
TimDaub
added a commit
to attestate/vhtml-memory-safe
that referenced
this pull request
Oct 21, 2025
- Replace LRU cache with WeakMap approach from PR developit#43 - Use String objects as WeakMap keys for automatic garbage collection - Memory bounded to active rendering context, no manual management needed - Update tests to use valueOf() to convert String objects to primitives Fixes developit#20, developit#34 Based on: developit#43
|
This won't work because we're now returning strings |
TimDaub
added a commit
to attestate/vhtml-memory-safe
that referenced
this pull request
Oct 21, 2025
- Replace unbounded cache with WeakMap - Return String objects instead of primitives - String objects can be WeakMap keys and are GC'd automatically - No eviction issues - entries only released when truly unreferenced - Requires calling .valueOf() on final result before serialization This approach is based on PR developit#43 but adapted for server-side usage.
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.
Adding a new PR here to start the discussion on solving #20 again.
PR Switch to a WeakMap to avoid memory leak #23 aims to solve SSR Memory leak #20 by switching to WeakMap, but it uses string primitives as keys and will throw
TypeError: Invalid value used as weak map key.PR Switch sanitization to a Set and add cleanup #36 switches to a Set for storing the sanitized strings, but we risk evicting strings from the set before using them, changing the output of
vhtml()to escaped text.This PR switches to WeakMap (as in #23), but uses string objects as keys. This will have a performance impact, and change the output from
vhtml()from string primitives to string objects.The question is if it's worth taking the performance impact to solve both #20 and #34.