Performance Engineering

Parser-Rewrite für gemeinsam genutzte Library

Ein gemeinsam genutzter Parser fügte großen medizinischen Leistungsabfragen mehrere Sekunden hinzu. Ich benchmarkte den Bottleneck, ersetzte teures Merge-Verhalten durch Map-basierte Lookups und brachte den Parser in Richtung vorhersehbarer linearer Arbeit.

Rolle: Untersuchung, Benchmarking, Umsetzung, Unterstützung beim Rollout
Ergebnis: repräsentative Workloads verbesserten sich von rund 25 Sekunden auf etwa 1 Sekunde, Benchmark-Tests zeigten 25-mal schnellere Parserläufe und reale Ladezeiten sanken aus Anwendersicht um rund 80 %.

Repräsentativer Workload: 25 s auf 1 s
Gemessener Parser-Speedup: 25-mal schneller
Ladezeit für Anwender: rund 80 % niedriger

Problem

Große Antworten aus der Leistungserfassung wurden durch einen QStruct-to-JSON-Konvertierungspfad verlangsamt. Technisch war es ein Parserproblem, produktiv bedeutete es mehrere zusätzliche Sekunden Wartezeit bei eigentlich alltäglichen Antworten.

Der langsame Pfad führte wiederholt Array-Merges aus und erzeugte laufend neue Objekte, während die Datenmenge wuchs. Dadurch wurden größere Fälle überproportional teuer.

Benchmark-Grafik zum Parser-Rewrite mit deutlich schnellerer optimierter Implementierung — Benchmark-Ausgabe aus dem Parser-Rewrite. Der öffentlich relevante Punkt ist die Größenordnung der Verbesserung, nicht die interne Datenstruktur.

Ansatz

Optimierter Parser-Pfad Der Rewrite entfernte wiederholte vollständige Array-Scans aus dem Hot Path und gruppierte geparste Einträge über direkte Key-Lookups.


                          flowchart LR
    Input[QStruct Input] --> Parse[RegExp Parse]
    Parse --> Group[Map-Gruppierung]
    Group --> Output[JSON Output]

    Old[Wiederholte Array-Scans] -. entfernt .-> Group

Wiederholbare Benchmarks mit einem repräsentativen 4-KB-QStruct-Content-Feld aus einem Standard-Leistungseintrag aufgebaut.
Wiederholte lodash-Array-Merges durch Map-basierte Lookups mit konstanter Zugriffzeit und direktes Anhängen an bestehende Schlüssel ersetzt.
Langsamere reguläre-Ausdruckspfade durch schnellere native JavaScript-RegExp-Ausführung ersetzt, wo es zum Parservertrag passte.
Den Rewrite auf die gemeinsam genutzte Library fokussiert, damit alle konsumierenden Workflows ohne duplizierte Optimierungen profitieren.

Warum es wichtig war

Die Verbesserung war nicht nur eine schnellere Funktion. Sie entfernte einen unternehmensweiten Bottleneck aus Healthcare-Workflows, in denen große Fälle normal sind, senkte Server Response Time und machte die gemeinsame Parser-Library robuster für zukünftiges Wachstum.

Wichtige Kennzahlen

Problem

Ansatz

Warum es wichtig war