test: add benchmarks for cache fill cost and retained cache size - #769
Open
veksa wants to merge 2 commits into
Open
test: add benchmarks for cache fill cost and retained cache size#769veksa wants to merge 2 commits into
veksa wants to merge 2 commits into
Conversation
✅ Deploy Preview for reselect-docs canceled.
|
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
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.
The benchmarks we have call each selector with 30 unique arguments, twice over, so filling the cache and reading it back land in the same number. Nothing measures how a miss gets more expensive as the cache grows, and nothing measures cache size at all — the one attempt at it,
describe.skip('weakMapMemoize memory leak')inweakMapMemoize.bench.ts, has been skipped since it was written.So this adds two benchmark files.
cacheWarmup.bench.tsmeasures the two paths separately. The cold suite clears the cache in tinybench'sbeforeEach, which runs outside the timed region, so every measured call is a miss; the warm suite fills the cache once insetupand never clears it. Plus a sweep over 1k/10k/100k keys, and a startup suite that creates 1,000 selectors, calls them for the first time, then calls them warm. Iterations are 30 rather than the 10 the other files use — filling a cache allocates, and GC lands on random iterations.cacheMemory.bench.tsreports retained heap instead of time — thehz/meancolumns are not meaningful there, which the file says at the top:benchnow runs throughnode --expose-gc, the same waytestalready does, since the memory numbers need forced collection. Without the flag they warn and still run.The second commit adds
scripts/weakMapMemoizeHeapSnapshot.mjs(yarn heap-snapshot). The benchmarks above say how much a filled cache retains; this says what is in it. It fills a selector the way #635 describes — one long-lived object argument, one primitive argument that keeps taking new values — then writes a V8 heap snapshot and prints a per-type summary:Two cache nodes per entry, one in the
argsMemoizetree and one in thememoizetree, plus the result each of them holds. The written.heapsnapshotloads into Chrome DevTools for retained sizes and retainer chains, which is what the printed shallow sizes cannot give you. Flags:--memoize=weakmap|lru,--entries=N,--out=path;*.heapsnapshotis gitignored.This commit is separable: drop it and the benchmarks still stand.
Two caveats worth stating up front. The result functions here are deliberately cheap, so the numbers reflect memoization bookkeeping rather than payload — a selector whose result function does real work will look different, and the warm column is where
weakMapMemoizepays off. And timings move between runs; the 100,000-key row ranged from 67 ms to 92 ms on the same machine, so compare rows within one run rather than numbers across runs.Related: #635.