Skip to content

findAll: defer slips initialization (~20MB RAM savings)#2539

Open
christopherkmoore wants to merge 1 commit into
Windower:devfrom
christopherkmoore:fix/findall-defer-slips-loading
Open

findAll: defer slips initialization (~20MB RAM savings)#2539
christopherkmoore wants to merge 1 commit into
Windower:devfrom
christopherkmoore:fix/findall-defer-slips-loading

Conversation

@christopherkmoore
Copy link
Copy Markdown

Summary

  • Defers slips.storages:map() from module load time to first search() call
  • Prevents ~20MB of res.items entries from materializing into memory at addon load
  • Result is cached after first search, so subsequent searches have no additional cost

Problem

At module level (line 195-198), findAll iterates every storage slip ID and accesses res.items[id] for each to build merged_storages_orders. This forces Windower's lazy-loading resource system to materialize hundreds of item entries into memory (~20MB).

This data is only needed when performing a search, not at idle.

Solution

Wrap the slips order initialization in ensure_merged_storages_orders(), called at the top of search(). Built once on first search, cached for subsequent searches.

Impact

  • Idle memory: ~27MB → ~700KB
  • First search: ~235ms one-time cost for cold res.items lookups (imperceptible)
  • Subsequent searches: no change
  • Multiboxers (6+ clients): saves ~150MB+ total RAM

Testing

  • Verified //findall searches return correct results across all storage types including slips
  • Verified tracker functionality unaffected
  • Benchmarked cold res.items[id] lookups at ~0.2ms each (1000 lookups in 235ms)

The `slips.storages:map()` call at module level iterates every storage
slip ID and accesses `res.items[id]` for each, forcing Windower's
lazy-loading resource system to materialize a large portion of the item
database into memory (~20MB).

Defer this initialization to the first `search()` call. The slips
order only needs to be built once and is cached for subsequent searches.

Cold `res.items[id]` lookups benchmark at ~0.2ms each, so the first
search has negligible additional latency. Idle memory drops from ~27MB
to ~700KB.

For multiboxers running 6+ clients this saves ~150MB+ of RAM across
all instances.
@christopherkmoore
Copy link
Copy Markdown
Author

I didn't do too much testing on this other than works on my machine. Claude helped me clean this up and it seems sensible with much better memory footprint after his change -- so I'll leave it up to you all to decide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant