# Erweiterungen für NodeMetrics und Analyse-Strategie

Durch die `NodeMetrics`-Dekoration können wir Daten sammeln, die entweder den **Optimizer steuern** oder dem **Linker/VM** bei der effizienten Ausführung helfen. Da der Optimizer den AST massiv verändert, müssen wir zwischen zwei Analyse-Phasen unterscheiden.

## Die Multi-Pass Strategie

1.  **Pre-Optimization Analysis (Pass 1):** Sammelt Heuristiken, um Optimierungen (Inlining, Folding) überhaupt erst zu ermöglichen oder zu begrenzen.
2.  **Optimizer:** Transformiert den Baum (Inlining dupliziert Code, DCE löscht Code).
3.  **Post-Optimization Analysis (Pass 2):** Berechnet die finalen, exakten Fakten für das Backend (VM/Linker), basierend auf dem "geschrumpften" Baum.

---

## 1. Steuerungs-Metriken (Pre-Optimization)
*Helfen dem Optimizer, Entscheidungen zu treffen.*

### A. Estimated Complexity Score
*   **Was:** Anzahl der Knoten im AST-Zweig.
*   **Nutzen:** Inlining-Budget. Statt fixer Tiefe wird nach Größe entschieden: "Inline diese Funktion nur, wenn sie < 20 Knoten hat."

### B. Initial Mutation Status
*   **Was:** Wird eine Variable (Local/Global) jemals mit `Set` verändert?
*   **Nutzen:** Wenn nein, kann der Optimizer sie wie eine `const` behandeln und den Wert überall dort einsetzen, wo sie gelesen wird (Aggressive Inlining).

### C. Purity (Bereits implementiert)
*   **Nutzen:** Erlaubt Constant Folding und das Entfernen von ungenutzten Aufrufen (DCE).

---

## 2. Backend-Metriken (Post-Optimization)
*Werden nach der Optimierung neu berechnet, um der VM/Linker Fakten zu liefern.*

### A. Final Usage Counts (Dead Code Elimination)
*   **Was:** Wie oft wird eine Funktion/Variable im *finalen* Code noch referenziert?
*   **Nutzen:** Globale Funktionen, die nach dem Inlining nirgends mehr aufgerufen werden, können vom Linker komplett aus dem Environment entfernt werden.

### B. Escape-Analyse (Closure-Optimierung)
*   **Was:** Verlässt eine Lambda-Instanz ihren Erzeugungs-Scope (z.B. als Rückgabewert)?
*   **Nutzen:**
    *   **Stack vs. Heap:** Nicht-escapende Lambdas können von der VM auf dem Stack (oder in einem Pool) verwaltet werden, statt teure Heap-Allocations für das `Closure`-Objekt auszulösen.
    *   **Direct Call:** Aufrufe solcher Lambdas können zu direkten Sprüngen/Calls optimiert werden.

### C. Resource Requirements
*   **Was:** Maximale Stack-Tiefe, Anzahl benötigter Register/Slots.
*   **Nutzen:** Die VM kann beim Aufruf exakt den benötigten Speicher reservieren, ohne dynamisch wachsen zu müssen.

---

## Fazit
Einige Werte (wie `UsageCount` oder `Complexity`) sind vor der Optimierung nur Schätzungen, da der Optimizer sie durch Code-Duplikation (Inlining) oder Löschung (DCE) verändert. Erst der zweite Analyse-Pass nach dem Optimizer liefert die "Wahrheit", die für Backend-Optimierungen wie die Escape-Analyse kritisch ist.