0.2: per-mod attribution, who is eating the tick

[Pixnop]

The next big one. Pulse 0.1 tells you the server spends 28 ms of work per tick; the question every admin asks next is which mod is responsible, and nothing on the ModDB answers it.

Three doors, surveyed and real:

1. A Harmony patch on the engine's FrameProfilerUtil, the way Temporalog's slow-tick logging works: when the engine's own profiler flags a slow tick, the call tree names the systems and listeners that consumed it. Turned into labelled counters (pulse_slow_tick_blame_total{owner}), this is direct attribution on exactly the ticks that matter. Cost: Harmony enters the zip (collision surface, the reason the base mod is dependency-free today), and profiling must be strictly opt-in config since the engine's profiler has a real per-tick cost when enabled.
2. Reflection over the engine EventManager's listener lists: how many tick listeners and callbacks each mod has registered. A load proxy, not a measurement, but cheap and always on. Temporalog has run this for two years behind a defensive try/catch.
3. StratumEntityBehaviorTimings on Stratum servers: per-behavior, per-entity-type tick time, drainable, compiled into their vsapi. Runtime feature detection with a clean fallback on vanilla and Lithos.

Also in scope per the original project brief: ingesting tsu's logger overload detections as labelled counters, which makes #6 (the observability-lanes conversation with the team) the natural entry point for this work rather than an afterthought.

Open questions to settle before code: whether attribution ships in the base zip behind config or as a third optional mod (the Harmony dependency suggests the latter, same reasoning as pulseotlp); what the owner label is keyed on (mod id where recoverable, type name where not); and what the always-on versus opt-in split is.

Target: 0.2. Blocked on the #6 conversation only for the tsu-logger part; the FrameProfiler and reflection doors can be designed now.

[Pixnop]

Feasibility survey done (two full reports in .survey/, engine decompile + Stratum sources + Probe). Verdict: GO, and the route is not the one this issue guessed.

The engine already contains a per-mod tick attributor; it is public and switched off. When sapi.World.FrameProfiler.Enabled is true, the server swaps to EventManager.TriggerGameTickDebug, which stamps a profiler mark after every game tick listener, delayed callback and main-thread entity behavior, keyed by the declaring type of the handler's target. The whole read path is public API: FrameProfiler.PrevRootEntry.Marks, and type-to-mod mapping via api.ModLoader.Mods + Mod.Systems. No Harmony, no engine patch; one read-only internal walk (EventManager listener lists, where GameTickListener.Handler is a public field) sharpens the mapping and degrades to 'unattributed' if internals move. The sleep is itself a named bucket, so busy share per mod falls out directly.

Costs are real but manageable. Full marks cost ~50-60 ns each and scale with entities x behaviors: ~2.8% of the tick budget on a 20-player/4k-entity server, ~10% at 20k entities. So: duty-cycle it (e.g. 30 ticks every 10 s, ~0.3% amortised) instead of leaving it on. A free coarse tier exists (PrintSlowTicks with an unreachable threshold) giving per-engine-phase marks at ~40/tick.

Two hazards, both handled by design. (1) Flipping Enabled mid-tick on a never-primed profiler NREs outside the tick's try/catch and kills the process: prime once during the RunGame run phase, before the loop exists, then toggling is safe. (2) ProfileEntry.ElapsedTicks is an int and wraps negative past 2.147 s inside one tick, exactly the pathological tick an operator wants explained: clamp on read.

What this route cannot see, to say up front in the docs: ~40 broadcast events (PlayerJoin, DidBreakBlock...) carry no marks at all; threadsafe physics is marked for the main-thread slice only, so that series must be labelled a main-thread share.

Division of labour with the rest of the team's tooling, for #6: Lithos Probe (tsu) already ships mod-attributed CPU with call trees via EventPipe sampling, on vanilla, 15-min retention: the point-in-time deep dive. Pulse's lane is the continuous per-mod time series on the scrape endpoint, which nothing else covers. Stratum's StratumEntityBehaviorTimings is not readable from outside as it stands (the engine reasserts the enable flag every tick, and Drain() is destructive, so reading steals the admin's own /stratum timings data): the thing to propose upstream is a non-destructive Snapshot(), a refcounted enable, and a ContractVersion const. Found along the way: /stratum timings listeners only walks server.EventManager and misses everything in ModEventManager, i.e. most mod listeners; worth a small upstream PR.

Suggested shape for the wave, when #6 settles: pulse_mod_tick_seconds_total{modid} + pulse_mod_tick_share from the duty-cycled profiler, off by default behind an Attribution config block, everything in the base dll (no new dependencies).

[Pixnop]

Shipped in #50 and released as v0.2.0-indev.2: pulse_mod_tick_share{modid}, pulse_mod_tick_seconds_total{modid}, pulse_attribution_ticks_total and pulse_attribution_dropped_samples_total, from the engine's own frame profiler driven in duty-cycled bursts, off by default. The survey reports live in .survey/ and the README's Attribution section documents the blind spots.