Phase 4: Ereignisschleife und klassische Traps

openspec/changes/archive/2026-09-04-phase-4-ereignisschleife/messung.md

@@ -0,0 +1,29 @@
+# Messung: Kosten der Ereigniszustellung (Aufgabe 8.1)
+
+`cargo bench -p tb-vm --bench vm`, Release, dieselbe Maschine. „Vorher" ist
+der Stand von `060674b` in einem eigenen Worktree, „nachher" der Median aus
+drei Läufen dieses Changes.
+
+| Last | vorher | nachher | Abweichung |
+|---|---|---|---|
+| INTEGER-Schleife (10 Mio) | 898 ms | 901 ms | +0,3 % |
+| DOUBLE-Schleife (5 Mio) | 419 ms | 429 ms | +2,4 % |
+| SUB-Aufrufe (1 Mio, BYREF) | 94 ms | 96 ms | +2,1 % |
+| String-Funktionen (200k) | 86 ms | 83 ms | −3,5 % |
+
+**Deutung.** Zwei Änderungen wirken hier zusammen, und nur die zweite kostet:
+
+1. **Die Zustellprüfung** an der Anweisungsgrenze ist ein einzelner
+   Bool-Test (`traps.aktiv()`, ein gepflegtes Feld). Ohne definierten Trap
+   fällt sie sofort durch; die Uhr wird gar nicht erst gelesen. Das ist im
+   Rauschen nicht auffindbar.
+2. **Die zusätzliche Anweisungsgrenze je `FOR`-Durchlauf** (design.md, D10)
+   ist eine Instruktion mehr pro Iteration. Sie erklärt die ~2 % auf den
+   schleifenlastigen Lasten und ist bewusst bezahlt: ohne sie ist
+   `FOR i = 1 TO n: NEXT` für Ereignisse, Breakpoints und Abbruch taub.
+   `DO`/`WHILE` zahlen nichts, dort zeigt der Rücksprung auf eine ohnehin
+   vorhandene Grenze.
+
+Die Streuung zwischen den Läufen liegt bei ±1,5 % (String-Last sogar
+schneller als vorher), die 2 % sind also am Rand der Auflösung dieses
+Harness — als obere Schranke aber belastbar.