← modperf

Static footprint 1.1 — methodology

This is a static-analysis grade. It is computed from the mod's code alone — which engine methods it overrides, how often those fire, how many timers it keeps alive — with no runtime measurement of the mod. Runtime performance of a live server is a different question answered by different instruments; when modperf gains measured data it will appear as a separate axis, never folded into this letter.

The Footprint grade is a structural load estimate at a declared reference operating point — like a benchmark score or an appliance energy label, the operating point is part of the metric's definition. It is not a lag prediction for any particular server.

What it prices

Chain dispatch: every server-visible modded class override link × its surface's dispatch rate × κ = 24.8 ns per link per dispatch (measured). Timer residency: every repeating literal-period timer registration × τ = 140.0 ns per live timer per frame (measured) — holding a timer costs more per frame than five chain links dispatch, so for slow timers residency dominates firing.

Measure it yourself

The constants above are checkable, not asserted. An open-source server-side benchmark mod, modperf-bench (MIT, also on the Steam Workshop), re-measures them on any test server: timer residency and firing cost under an A/B/A′ protocol with an explicit noise floor, inventory-lookup cost, and the price of the per-frame-accumulator pattern. Runs are self-invalidating — a suite whose recovery window does not return to baseline reports itself untrustworthy rather than shipping a number. Its first published calibration run found that the gameplay call queue is walked per simulation tick, not per engine frame, so the residency constant's unit is under review for the next rubric version — exactly the kind of correction the benchmark exists to force. Never run it on a populated server; it degrades frame time by design.

What it does not price — read this before quoting a grade

Hook body cost, timer body cost, network egress, and all engine-side effects are unpriced. Measured evidence from the underlying research: on heavily degraded servers, ~97% of stall mass sits outside mod script chains entirely — a good grade does not clear a server of lag, and a bad grade does not convict one.

Reference operating point

• Population 100
• Reference frame rate 1000 fps
• Player command tick 30 Hz/player (measured, fixed)

Per-surface rates

Rates tagged placeholder are declared assumptions awaiting measurement; every report separates their contribution.

Grade bands

The grade is the band the mod's structural load falls into, on a log scale of share of each server frame at 100 players (1 ms/s of main thread = 0.1% of a frame). The same axis is drawn on every scorecard's Expected-impact meter, so a grade and a meter position always agree.

Versioning & gaming

The rubric is versioned; when constants improve, a new version reprices every mod and cross-version grades are not comparable (the benchmark convention). Because bodies are unpriced, consolidating work into fewer, fatter hooks improves the grade without reducing work — which is why body-relevant patterns (loops over players in hooks, main-thread file I/O, timers registered in event paths) are surfaced as separate findings that a grade can never absorb.