# 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.