The problem
S3maphore resolves playlists in priority order. If that order is stable between registrations, sorting the same decks during every resolution is work that does not change the answer.
It is easy to miss because sorting is not a dramatic operation. It is simply in the wrong place.
The reduction
Ask when the ordering becomes known:
If the input is stable, why are we re-establishing its order in the hot path?
Commit 5b1537b5 moved playlist sorting to the initialization boundary. The current music core sorts each deck after loading completes, while the playlist catalog re-sorts when a ready catalog changes. Normal selection walks already ordered decks.
This is not a LuaJIT trick. It is a placement decision: establish stable facts at the boundary where the data enters, then make the runtime path consume them.
Why this works
Moving stable work cold does three things:
- removes repeated work from a path that may run often;
- makes the hot path's assumptions visible;
- gives registration and loading code ownership of order changes.
The optimization is safe only because the ordering contract is explicit. When a playlist is registered, removed, or its priority changes, the catalog must restore the ordering before resolution uses it. The priority rules document the semantic ordering; the catalog owns maintaining the data structure.
What to steal
Look for work whose answer depends only on stable input: sorting, parsing, path normalization, lookup-table construction, and validation are common examples.
Do it once when the data enters the system. Keep the invalidation path responsible for rebuilding it when the input actually changes.
This is the approachable beginning of the performance path. Measure First tells you how to establish whether repeated work matters before moving it.
When not to use this
Do not move work out of the runtime path if its inputs can change there or if rebuilding it is cheaper than maintaining invalidation. A stale “cold-path” result is worse than a small repeated calculation.