Repository navigation
Warm the tile cache in the background so the map opens on the 13 ms path #161
Description
Split out of #157. Nothing parses a region until somebody looks at it, so the map is always cold the first time it is opened after an update or on a world MSMS has not seen.
The two paths are far apart:
region parsed cold 1442 ms
region read from the cache 13 ms
A viewport is 4-9 regions, so first-open is seconds and re-open is well under a tenth of one. Walking the region directory in the background and parsing into the on-disk cache would make the common case the 13 ms path.
Constraints that matter:
- it must not fight the interactive queue — a visitor looking at the map has to win over the warmer
- it must respect
MapPerfConfig:cache: falsemeans no warming at all, andcacheLimitMBstill caps the result, so warming a world larger than the cap just evicts its own earlier work (decide whether to warm at all in that case, or warm nearest-to-spawn first) - a big explored world is thousands of regions; this should be bounded and resumable rather than a startup stall
- ordering by region mtime, or by distance from spawn, is likely better than directory order
Sequence this after #160 — warming on the main thread would be the freeze this is meant to avoid, at a larger scale.
Activity
Parse regions on worker threads, and warm the cache before anyone loo…
CaYatur commentedon Aug 5, 2026
Done in #165, alongside #160 — the two belong together, since warming on the main thread would have been the freeze it exists to avoid at a larger scale.
The warmer walks each dimension's region directory outward from the origin, parses on the worker pool when nobody is waiting, and:
sweepCacheevicts oldest-first, so on a world bigger than the limit it would have spent every pass deleting the spawn area and keeping whichever far corner it wrote last — worse than not warming at all, and only on the big worlds this was for.