You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Collecting high‑frequency, time‑series metrics from a complex simulation requires an architecture that is **performant, maintainable, and extensible**. Our design meets those goals by keeping metric *declaration*, *state management,* and *data collection* in strictly separate layers.
4
+
5
+
\### 1 Guiding Principles & Architecture
6
+
7
+
1.**Minimal Hot‑Path Overhead** — every state update in the simulation core is `O(1)`.
8
+
2.**Single Source of Truth** — one “Registry” enumerates every metric that can exist.
9
+
3.**User‑Defined Extensibility** — advanced users can register custom metrics without touching the framework.
10
+
4.**Predictable Memory Footprint** — data structures are pre‑allocated once, never rebuilt at each sample tick.
Even with the new properties, the guard remains essential:
81
+
82
+
***Robustness** — prevents `KeyError` when a metric is disabled for a given edge.
83
+
***Extensibility** — a user can add `EDGE_PACKET_LOSS` (or any custom metric) to a subset of edges; the collector automatically respects that configuration.
84
+
85
+
This single `O(1)` check keeps the system plug‑and‑play while preserving full encapsulation:
0 commit comments