💻 computer science

JEDI: Java Evaluation of Declarative and Imperative Queries

Dieser Beitrag stellt JEDI vor, eine automatisch generierte Benchmark-Suite, die SQL-Abfragen in Java übersetzt, um die Leistung deklarativer Stream-API-Implementierungen mit imperativen Baselines zu bewerten und zu vergleichen, mit dem Ziel, ineffiziente Code-Muster zu identifizieren und die Optimierung der Java Stream API zu unterstützen.

Ursprüngliche Autoren: Filippo Schiavio, Walter Binder

Veröffentlicht 2026-05-25

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Filippo Schiavio, Walter Binder

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben ein riesiges Lager voller Kartons (Daten), und Sie müssen spezifische Gegenstände finden, sortieren und zählen. Sie haben zwei Möglichkeiten, Ihren Arbeitern Anweisungen zu geben:

Der „Manager"-Ansatz (Imperativ): Sie gehen zu jedem Arbeiter einzeln hin und sagen: „Nimm diesen Karton auf. Prüfe, ob er rot ist. Wenn ja, leg ihn auf einen Stapel. Wenn nein, wirf ihn weg. Nimm jetzt den nächsten." Das ist sehr direkt und schnell, erfordert aber viel Gespräch und kann chaotisch werden, wenn Sie Tausende von Arbeitern haben.
Der „Vorarbeiter"-Ansatz (Java Stream API): Sie schreiben eine einzige, elegante Notiz: „Nehmen Sie alle Kartons, filtern Sie die roten heraus, sortieren Sie sie nach Größe und zählen Sie sie." Sie geben diese Notiz einem Vorarbeiter, der herausfindet, wie er die Arbeiter dazu bringt, es zu tun. Das ist für Sie viel einfacher zu schreiben und zu lesen, aber der Vorarbeiter muss Ihre Notiz in Handlungen übersetzen, was manchmal zusätzliche Zeit kostet.

Dieses Papier mit dem Titel JEDI dreht sich darum zu testen, wie gut der „Vorarbeiter" (die Java Stream API) im Vergleich zum „Manager" (traditioneller Code) abschneidet, und herauszufinden, wie man den Vorarbeiter schneller arbeiten lassen kann.

Das Problem

Die Java Stream API ist beliebt, weil sie Code sauber und leicht verständlich macht (wie die Notiz an den Vorarbeiter). Entwickler haben jedoch vermutet, dass diese „saubere" Art, Code zu schreiben, langsamer ist als die „chaotische" traditionelle Methode. Das Problem ist, dass niemand eine ordentliche Rennstrecke (einen Benchmark) hatte, um dies fair zu testen. Ohne eine Rennstrecke wissen die Leute, die die Java-Sprache bauen (die „Mechaniker"), nicht genau, wo der Motor stottert, und Entwickler wissen nicht, welche Anweisungen die beste Geschwindigkeit liefern.

Die Lösung: JEDI

Die Autoren haben JEDI (Java Evaluation of Declarative and Imperative Queries) entwickelt. Denken Sie an JEDI als eine riesige, automatisierte Fabrik, die Standard-Datenbankabfragen (geschrieben in einer Sprache namens SQL, die wie ein universelles Anforderungsformular ist) nimmt und sie sofort in zwei verschiedene Sätze von Anweisungen übersetzt:

Einen Satz im „Vorarbeiter"-Stil (Streams).
Einen Satz im „Manager"-Stil (imperative Schleifen).

Da die Fabrik die exakt gleiche Frage in beide Stile übersetzt, ist der Vergleich perfekt fair. Es ist, als würde man zwei Läufern exakt denselben Weg geben und sie stoppen, um zu sehen, wer schneller ist.

Was sie herausfanden

1. Kleine Anpassungen machen einen großen Unterschied (Die „Filter-Fusion")
Manchmal gerät der Vorarbeiter in Verwirrung, wenn Sie ihm drei separate Notizen geben: „Prüfe auf Rot", „Prüfe auf Groß", „Prüfe auf Schwer".

Die Lösung: Die Autoren stellten fest, dass das Zusammenfassen dieser zu einer großen Notiz („Prüfe auf Rot UND Groß UND Schwer") den Vorarbeiter viel schneller macht. Es ist, als würde man einem Arbeiter eine klare Anweisung geben statt drei verwirrenden.
Das Ergebnis: Diese einfache Änderung ließ den Code in einigen Fällen bis zu 2,6-mal schneller laufen.

2. Der „Eins-zu-Viele"-Trick
Manchmal enthält ein einzelner Karton viele kleinere Gegenstände.

Der alte Weg: Der Vorarbeiter würde den Karton nehmen, öffnen, einen Gegenstand herausziehen, auf einen Stapel legen, zurückgehen, den nächsten herausziehen und wiederholen.
Der neue Weg: Die Autoren fanden ein spezielles Werkzeug (genannt mapMulti), das es dem Vorarbeiter ermöglicht, den Karton zu öffnen und alle Gegenstände auf einmal in einer flüssigen Bewegung herauszuschütten.
Das Ergebnis: Dies war sogar effektiver als der erste Tipp und verdoppelte oft die Geschwindigkeit.

3. Das Parallelismus-Rätsel (Viele Arbeiter einsetzen)
Wenn Sie ein riesiges Lager haben, wollen Sie viele Arbeiter gleichzeitig einsetzen (parallele Verarbeitung). Das Papier testete vier verschiedene Möglichkeiten, diese Arbeiter zu organisieren:

Das „Streng geordnete" Team: Alle arbeiten in einer Reihe und geben Kartons weiter. Gut für die Wahrung der Ordnung, aber langsam.
Das „Chaos"-Team: Alle greifen sich zufällig Kartons. Schnell, aber schwer zu managen.
Das „Geteiltes Board"-Team: Alle schreiben ihre Ergebnisse auf eine riesige, gemeinsame Whiteboard.
Das „Atomare" Team: Alle verwenden einen speziellen, hochtechnologischen Stift, der niemals verschmiert, selbst wenn zwei Personen gleichzeitig schreiben.

Das Urteil: Es gibt kein einziges „bestes" Team.

Wenn Sie sehr wenige Gruppen von Gegenständen zu sortieren haben (wie nur 4 Obstsorten), sind das „Streng geordnete" oder das „Chaos"-Team am schnellsten, weil das „Geteilte Board" zu überfüllt wird (zu viel Streit darüber, wer zuerst schreibt).
Wenn Sie Tausende von Gruppen haben (wie 10.000 verschiedene Obstsorten), gewinnt das „Geteilte Board"-Team, weil der Streit aufhört und jeder seinen eigenen Abschnitt schreiben kann, ohne andere zu behindern.

4. Die Geschwindigkeitslücke
Die große Frage: Ist der „Vorarbeiter" (Stream) langsamer als der „Manager" (Imperativ)?

Ja. Der traditionelle „Manager"-Code ist konsequent schneller, normalerweise um etwa 30 % bis 40 %.
Warum? Der „Vorarbeiter" muss Zeit damit verbringen, Ihre elegante Notiz in Handlungen zu übersetzen. Der „Manager" erledigt die Arbeit einfach sofort.
Die gute Nachricht: Die Lücke ist nicht so riesig, wie viele in der Vergangenheit dachten. Das Java-Team hat den Motor verbessert. Für die absolut schnellste Leistung gewinnt jedoch immer noch der „Manager"-Stil.

5. Der Kompromiss: Geschwindigkeit vs. Vernunft
Das Papier untersuchte auch, wie schwer der Code zu lesen ist.

Der „Manager"-Code (schnellste) ist wie ein dichter, verwirrender Handbuch. Er ist schwer zu lesen und anfällig für Fehler.
Der „Vorarbeiter"-Code (langsamer) ist wie eine klare, kurze Geschichte. Er ist viel leichter zu verstehen und weniger fehleranfällig.
Die Lehre: Sie müssen wählen. Wollen Sie, dass der Code 30 % schneller läuft, oder wollen Sie, dass er für Menschen 2,5-mal einfacher zu lesen und zu warten ist? Das Papier schlägt vor, dass für die meisten Menschen der „Vorarbeiter"-Stil die kleine Geschwindigkeitseinbuße wert ist, weil er Zeit beim Debugging und bei der Wartung spart.

Zusammenfassung

JEDI ist ein neues Werkzeug, das Entwicklern hilft, die „Kosten" der Verwendung der modernen, leicht lesbaren Java Stream API zu verstehen. Es beweist, dass zwar der leicht lesbare Code etwas langsamer ist als der altmodische Code, Sie ihn aber durch den Einsatz spezifischer Tricks (wie das Kombinieren von Filtern) viel schneller machen können. Es sagt Entwicklern auch genau, wie sie ihre Arbeiter organisieren sollen (Parallelisierungsstrategien), abhängig davon, wie viel Daten sie haben. Letztendlich gibt es Entwicklern eine Landkarte, um Code zu schreiben, der sowohl lesbar als auch angemessen schnell ist.

Technische Zusammenfassung: JEDI – Java Evaluation of Declarative and Imperative Queries

Problemstellung

Die in Java 8 eingeführte Java Stream-API bietet eine deklarativen Syntax zur Verarbeitung von Sammlungen und unendlichen Datenquellen mit dem Ziel, die Produktivität der Entwickler, die Lesbarkeit des Codes und die Wartbarkeit im Vergleich zu traditionellem imperativem, schlaufenbasiertem Code zu verbessern. Obwohl die API die parallele Berechnung durch hochlevelige Abstraktionen vereinfacht, zeigen bestehende Literaturquellen, dass Stream-basierte Implementierungen im Vergleich zu äquivalentem imperativem Code häufig unter Performance-Einbußen leiden.

Eine kritische Lücke, die in dieser Arbeit identifiziert wurde, ist das Fehlen dedizierter Benchmark-Suiten, die auf die Stream-API abzielen. Ohne solche Benchmarks ist es schwierig für:

Forscher und Bibliotheks-Entwickler: Die Implementierung der Stream-API innerhalb der Java Class Library (JCL) zu optimieren.
Anwendungs-Entwickler: Die Performance-Eigenschaften verschiedener Stream-Operationen und Parallelisierungsstrategien zu verstehen, um effizienten Code zu schreiben.

Aktuelle Benchmarks zielen entweder nicht explizit auf die Stream-API ab oder verlassen sich auf einfache, synthetische Pipelines, die komplexe, reale Datenverarbeitungslasten nicht widerspiegeln.

Methodik

Um diese Lücke zu adressieren, stellen die Autoren JEDI (Java Evaluation of Declarative and Imperative Queries) vor, eine Benchmark-Suite, die automatisch durch die Konvertierung von SQL-Abfragen in Java-Quellcode generiert wird.

Generierungsprozess

Quellmaterial: Die Autoren nutzen den TPC-H-Benchmark, einen weit verbreiteten Datenanalyse-Benchmark, der aus komplexen Abfragen besteht, die verschiedene Datenverarbeitungsfunktionen abdecken (Joins, Aggregationen, Filterung, Sortierung).
Code-Konvertierung: Die Autoren erweiterten ein bestehendes Tool, S2S (SQL to Stream), um SQL-Abfragen in mehrere semantisch äquivalente Java-Implementierungen zu konvertieren.
- Schema-Mapping: SQL-Tabellen werden auf Arrays von Objekten im Speicher abgebildet.
- Abfrage-Übersetzung:
  - SELECT-Projektionen $\rightarrow$ map(...)
  - WHERE-Prädikate $\rightarrow$ filter(...)
  - ORDER BY $\rightarrow$ sorted(...)
  - LIMIT $\rightarrow$ limit(...)
  - GROUP BY und Aggregationen $\rightarrow$ collect(...) mit generierten Collectors.
  - JOIN $\rightarrow$ Implementiert über flatMap (Erstellung einer Hash-Map für die Build-Seite) oder mapMulti.
Implementierungsvarianten: Für eine einzelne SQL-Abfrage generiert JEDI mehrere Varianten, um verschiedene Codierungsmuster und Ausführungsstrategien zu vergleichen:
- Sequenzielle Varianten:
  - O1 (Filter-Fusion): Kombination mehrerer Prädikate in einem einzigen filter-Aufruf versus mehrere verkettete Aufrufe.
  - O2 (Join-Implementierung): Verwendung von mapMulti versus flatMap für Join-Operationen.
- Parallele Varianten (O3):
  - P: Geordnete parallele Streams (parallel()).
  - PU: Ungeordnete parallele Streams (parallel().unordered()).
  - CG: Ungeordnete parallele Streams unter Verwendung von groupingByConcurrent (geteilter Zustand mit lock-basierter Synchronisation).
  - CGCC: CG mit thread-sicheren Downstream-Collectors (lock-freie atomare Operationen).
- Imperative Baseline: Eine schlaufenbasierte Implementierung unter Verwendung exakt derselben Datenstrukturen und Operationsreihenfolge wie die Stream-Versionen, um den „Overhead der Stream-API" zu messen.

Evaluierungs-Setup

Hardware: Zwei unterschiedliche Architekturen: Intel Xeon Gold (16 Kerne) und ARM Neoverse-N1 (80 Kerne).
JVMs: Oracle JDK 24 und GraalVM 24.
Datensätze: TPC-H-Skalierungsfaktoren von 1 (1 GB) für sequenzielle Analyse und 10 (10 GB) für parallele Analyse.
Werkzeuge: Java Microbenchmark Harness (JMH) mit Warmup und gemessenen Iterationen, um eine Performance im stabilen Zustand sicherzustellen.

Hauptbeiträge

JEDI Benchmark-Suite: Die Veröffentlichung einer Open-Source-Benchmark-Suite, die von TPC-H abgeleitet ist und automatisch semantisch äquivalente Stream- und imperative Implementierungen generiert.
Code-Generator: Eine erweiterte Version von S2S, die mehrere Implementierungsstrategien unterstützt (sequenzielle Optimierungen und verschiedene parallele Reduktionsmuster).
Performance-Leitlinien: Eine Reihe abgeleiteter Best Practices für die effiziente Nutzung der Stream-API basierend auf empirischen Daten.
Overhead-Analyse: Ein direkter Vergleich von Stream-basiertem versus imperativem Code unter Verwendung identischer Datenstrukturen und Operationsreihenfolgen, um die Performance-Kosten der API-Abstraktionen zu isolieren.

Ergebnisse und Erkenntnisse

RQ1: Sequenzielle Optimierungen (Filter-Fusion & Join-Implementierung)

Filter-Fusion (O1): Die Kombination von Prädikaten in einem einzigen filter-Aufruf verbessert die Performance, insbesondere wenn viele Prädikate vorhanden sind (z. B. 3,54-fache Beschleunigung in einem Mikrobenchmark mit 7 Prädikaten).
Join-Implementierung (O2): Die Verwendung von mapMulti anstelle von flatMap für Joins liefert signifikante Verbesserungen (geometrische mittlere Beschleunigung von 1,38-fach auf Intel JDK).
Fazit: Entwickler sollten O1 und O2 whenever möglich anwenden.

RQ2: Parallelisierungsstrategien

Kein universeller Gewinner: Keine einzelne Parallelisierungsstrategie dominiert alle Szenarien. Die Performance hängt stark von den Datenmerkmalen ab, insbesondere von der Anzahl der aggregierten Gruppen und der Art der Aggregation.
Skalare versus gruppierte Aggregationen:
- Für skalare Aggregationen (keine Gruppierung) oder kleine Anzahlen von Gruppen übertreffen geordnete (P) oder ungeordnete (PU) parallele Streams geteilter-Zustand-Strategien (CG, CGCC) aufgrund geringerer Kontention.
- Für gruppierte Aggregationen mit vielen Gruppen ist CG (unter Verwendung von groupingByConcurrent) im Allgemeinen die beste Strategie. Mit zunehmender Anzahl von Gruppen nimmt die Lock-Kontention ab, was lock-basierte Synchronisation effizient macht.
Lock-frei versus lock-basiert: CGCC (lock-frei) übertrifft CG (lock-basiert) nicht konsistent und führt Implementierungskomplexität ein. Allerdings ist CGCC robuster für sehr kleine Gruppengrößen, bei denen CG unter hoher Kontention leidet.
Distinct-Operationen: Obwohl ungeordnete Streams (PU) im Allgemeinen für distinct empfohlen werden, ergab die Studie, dass bei Streams mit einer geringen Anzahl von Distinct-Elementen geordnete parallele Streams (P) aufgrund des Overheads der Verwaltung eines geteilten ConcurrentHashMap in ungeordneten Streams bis zu 2-mal schneller sein können.

RQ3: Stream versus Imperative Performance

Imperative Überlegenheit: Imperativer, schlaufenbasierter Code übertrifft Stream-basierten Code konsistent.
Ausmaß: Die geometrische mittlere Beschleunigung von imperativem Code gegenüber der besten sequenziellen Stream-Implementierung reicht über verschiedene JVMs und Architekturen hinweg von 1,28-fach bis 1,41-fach.
Kontext: Obwohl dies frühere Erkenntnisse bestätigt, stellen die Autoren fest, dass die Lücke kleiner ist als in einigen früheren Studien, was auf Verbesserungen in der Stream-API-Implementierung im Laufe der Zeit hindeutet. Für performancekritischen Code bleibt imperativer Code jedoch erheblich schneller.

RQ4: Code-Komplexität

Lesbarkeit: Trotz der Performance-Lücke weist Stream-basierter Code signifikant niedrigere Komplexitätsmetriken auf.
Metriken: Die kognitive Komplexität der Baseline-Stream-Code ist 2,43-fach niedriger als bei imperativem Code. Selbst mit Optimierungen (O1+O2) bleibt Stream-Code 1,62-fach weniger komplex als imperativer Code.
Abwägung: Die Optimierung von Stream-Code (z. B. Fusionieren von Filtern) erhöht seine Komplexitätsmetriken, hält ihn jedoch unterhalb der Komplexität imperativer Äquivalente.

Bedeutung und Behauptungen

Das Papier positioniert JEDI als ein wichtiges Instrument sowohl für die Java-Community als auch für JVM-Implementierer:

Für Entwickler: Es bietet datengestützte Leitlinien, um den Performance-Overhead der Stream-API zu minimieren, und schlägt spezifische Muster vor (z. B. mapMulti, groupingByConcurrent für große Gruppen) basierend auf den Arbeitslastmerkmalen.
Für Bibliotheks-Implementierer: Die Benchmark-Suite und der identifizierte „Overhead" bieten eine Basislinie für die Optimierung der Stream-API-Implementierung, um die Performance-Lücke zu imperativem Code zu schließen.
Für Forscher: Es bietet eine reproduzierbare, komplexe Arbeitslast (von TPC-H abgeleitet), um zukünftige Optimierungen, Refactoring-Tools oder Parallelisierungsstrategien zu bewerten.

Die Autoren erkennen bescheiden Limitationen an und stellen fest, dass JEDI derzeit auf array-basierte Datenquellen und spezifische SQL-zu-Stream-Übersetzungsmuster fokussiert ist. Sie planen, den Generator in zukünftiger Arbeit zu erweitern, um mehr Stream-API-Methoden abzudecken und Datenquellen (z. B. Listen, Mengen) zu variieren.