You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 354e926
Browse filesBrowse the repository at this point in the historyBrowse files
Raise CachedParser source-byte cap to 4 MB, add eviction floor, make it configurable
The 512 KB cap from bf4d513 effectively shrank the 256-entry LRU to
~45 entries on WordPress: its hot working set includes 25 files over
100 KB (formatting.php, post.php, functions.php, ...) that everything
else pulls in through reflection, so all evictions were size-based and
the hottest files were re-parsed 100x per run. The WordPress
integration-test PHPStan step regressed from ~105 s to ~150 s (+42%);
locally +39% user CPU (274 s vs 197 s uncapped).
Sweep on WordPress (user CPU / median worker peak memory):
512 KB 274 s / 250 MB, 1 MB 250 s / 268 MB, 2 MB 225 s / 316 MB,
4 MB 199 s / 400 MB, uncapped 197 s / 542 MB. A typical project
(phpstan-src itself) has a natural LRU appetite of only 1.3 MB and is
unconstrained by the new default either way.
Since both the memory cost of a cached entry and the CPU cost of
re-parsing it scale with its source size, the value-per-byte of an
entry is its access frequency alone - eviction order should stay
recency-based, and the byte cap is only a memory safety net, so it must
be generous enough to hold a big project's hot working set.
The new eviction floor guarantees minimum residency: without it, a
single source larger than the whole cap would flush the entire cache on
every insertion, degenerating the cache to one entry when such sources
are hot.
The cap is exposed as cache.nodesByStringSourceBytesMax (0 = unlimited)
alongside the other cache limits.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012SoHaGT1YXNue8VzSKT7aG
0 commit comments