1.4 KiB
1.4 KiB
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:
- 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. - 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 istFOR i = 1 TO n: NEXTfür Ereignisse, Breakpoints und Abbruch taub.DO/WHILEzahlen 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.