RustAst/docs/Pipe Optimization.md

---

Stream & Pipe Optimization

1. Global Series Deduplication (The "Registry" Pattern)

Die aktuelle Architektur erzeugt für jeden Pipe-Eingang einen eigenen Akkumulator. Bei komplexen Graphen mit identischen Datenquellen führt dies zu redundantem Speicherverbrauch.

• Konzept: Einführung einer Global Series Registry, die als Mediator zwischen IStream und TPipeSource fungiert.
• Mechanismus: Anstatt eine TScalarSeries privat zu instanziieren, fordert die TPipeSource eine Serie über einen Composite-Key (IStream, IKeyword) an.
• Vorteil: Wenn zehn Pipes den Close-Preis desselben Tickers beobachten, existiert im gesamten Arbeitsspeicher nur eine einzige Instanz der Daten-Historie.
• Lookback-Management: Die Registry überwacht die Anforderungen aller Konsumenten und stellt sicher, dass die geteilte Serie immer den maximalen Lookback aller beteiligten Pipes vorhält.

---

2. Local State Optimization (Ring-Buffer Series)

Für Berechnungen innerhalb der Lambda-Funktion (z.B. kurzfristige Delta-Vergleiche) sind die auf Chunks basierenden TScalarSeries aufgrund ihrer Verwaltungs-Overheads ineffizient.

• Konzept: Implementierung spezialisierter Local Ring-Buffer, die für ultrakurze Lookbacks (z.B. ) optimiert sind.
• Mechanismus: Ein statisch allozierter Speicherblock mit truncate-on-add-Logik. Im Gegensatz zu Chunks gibt es hier keine Heap-Fragmentation durch dynamisches Wachsen.
• Scope: Diese Strukturen sind "Lambda-Local". Sie werden nicht über die Registry geteilt, sondern dienen als privater, blitzschneller "Scratchpad-Speicher" für zustandsbehaftete Berechnungen.

---

3. Signal Transmission & Pressure Relief

Das ständige Allokieren von TArray<TScalar.TValue> in der Emit-Methode erzeugt bei hohen Tick-Raten signifikanten Druck auf den Memory-Manager und das Reference-Counting.

• Konzept: Allocation Pooling oder Buffer Slicing für Signal-Payloads.
• Mechanismus: Einführung eines TValueBufferPool. Streams leihen sich ein Array für den Emit-Vorgang aus. Sobald der letzte Observer das Signal verarbeitet hat, kehrt das Array in den Pool zurück.
• Alternative: Nutzung von Record-basierten Memory-Slices, um Kopier-Operationen beim Erzeugen des Signals gänzlich zu eliminieren (Zero-Copy).

---

4. Runtime Adaptability (Dynamic Lookback)

Aktuell ist der Lookback einer Serie bei der Initialisierung festgeschrieben. In einem dynamischen System müssen Pipes jedoch zur Laufzeit hinzugeschaltet werden können.

• Konzept: Elastic Series Buffers.
• Mechanismus: Die TScalarSeries erhält die Fähigkeit, ihre Chunk-Kapazität dynamisch nach oben zu korrigieren, ohne die Integrität der bestehenden Indizes zu verletzen.
• Motivation: Dies ermöglicht "Hot-Swapping" von Logik-Komponenten. Eine neue Analyse-Pipe kann sich in einen laufenden Stream einklinken und eine Erweiterung der Historie anfordern, ohne dass das System neu gestartet werden muss.

---

5. Computational Economy (Lazy/Dirty Logic)

In tiefen Graphen werden oft Pipes getriggert, deren Eingangsdaten sich zwar im Cycle geändert haben, deren für die Berechnung relevante Werte aber identisch geblieben sind.

• Konzept: Change-Detection & Lazy Evaluation.
• Mechanismus: Jedes Signal erhält eine Versionierung. Pipes führen ihre Lambda nur aus, wenn sich die Versionen der Eingangs-Serien tatsächlich geändert haben oder wenn ein "Dirty"-Flag gesetzt ist.
• Ziel: Massive Einsparung von CPU-Zyklen in Szenarien, in denen viele Pipes auf hochfrequenten Streams hängen, aber nur selten Schwellenwerte überschritten werden.

---

Zusammenfassung der Architektur-Ziele

Fokus	Methode	Resultat
Memory	Global Registry	Eliminierung redundanter Daten-Historien.
Latency	Ring-Buffers	Beschleunigung lokaler Lambda-Berechnungen.
Throughput	Buffer Pooling	Minimierung von GC-Pausen und Allokations-Overhead.
Agility	Dynamic Lookback	Unterstützung von On-the-fly Rekonfiguration.

---