💻 computer science

JEDI: Java Evaluation of Declarative and Imperative Queries

Cet article présente JEDI, une suite de tests générée automatiquement qui convertit des requêtes SQL en Java pour évaluer et comparer les performances des implémentations déclaratives de l'API Stream par rapport à des bases impératives, visant à identifier des motifs de code inefficaces et à guider l'optimisation de l'API Stream de Java.

Auteurs originaux : Filippo Schiavio, Walter Binder

Publié 2026-05-25

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Filippo Schiavio, Walter Binder

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous possédiez un immense entrepôt rempli de boîtes (données), et que vous deviez trouver des articles spécifiques, les trier et les compter. Vous avez deux façons de donner des instructions à vos ouvriers :

L'approche « Manager » (Impérative) : Vous vous approchez de chaque ouvrier individuellement et dites : « Prends cette boîte. Vérifie si elle est rouge. Si oui, mets-la dans un tas. Si non, jette-la. Maintenant, prends la suivante. » C'est très direct et rapide, mais cela nécessite beaucoup de bavardage et peut devenir désordonné si vous avez des milliers d'ouvriers.
L'approche « Contremaître » (API Stream Java) : Vous écrivez une note unique et élégante : « Prenez toutes les boîtes, filtrez celles qui sont rouges, triez-les par taille et comptez-les. » Vous remettez cette note à un contremaître qui détermine comment faire exécuter cela aux ouvriers. C'est beaucoup plus facile à écrire et à lire pour vous, mais le contremaître doit traduire votre note en actions, ce qui prend parfois du temps supplémentaire.

Ce papier, intitulé JEDI, porte entièrement sur le test des performances du « Contremaître » (l'API Stream Java) par rapport au « Manager » (le code traditionnel), et sur la détermination de la manière de rendre le Contremaître plus rapide.

Le Problème

L'API Stream Java est populaire car elle rend le code propre et facile à comprendre (comme la note au contremaître). Cependant, les développeurs soupçonnaient que cette façon « propre » d'écrire du code était plus lente que la façon « désordonnée » traditionnelle. Le problème est que personne n'avait de véritable piste d'essai (un benchmark) pour tester cela équitablement. Sans piste d'essai, les personnes qui construisent le langage Java (les « mécaniciens ») ne savent pas exactement où le moteur bronche, et les développeurs ne savent pas quelles instructions offrent la meilleure vitesse.

La Solution : JEDI

Les auteurs ont construit JEDI (Java Evaluation of Declarative and Imperative Queries). Imaginez JEDI comme une usine gigantesque et automatisée qui prend des requêtes de base de données standard (écrites dans un langage appelé SQL, qui est comme un formulaire de demande universel) et les traduit instantanément en deux ensembles d'instructions différents :

Un ensemble utilisant le style « Contremaître » (Streams).
Un ensemble utilisant le style « Manager » (boucles impératives).

Comme l'usine traduit la même question exacte dans les deux styles, la comparaison est parfaitement équitable. C'est comme donner à deux coureurs exactement le même parcours et chronométrer pour voir qui est le plus rapide.

Ce qu'ils ont découvert

1. De petits ajustements font une grande différence (La « Fusion de filtres »)
Parfois, le Contremaître se confond si vous lui donnez trois notes séparées : « Vérifiez si rouge », « Vérifiez si grand », « Vérifiez si lourd ».

La Solution : Les auteurs ont découvert que combiner ces éléments en une seule grande note (« Vérifiez si rouge ET grand ET lourd ») rend le Contremaître beaucoup plus rapide. C'est comme donner à un ouvrier une instruction claire au lieu de trois instructions confuses.
Le Résultat : Ce simple changement a permis d'exécuter le code jusqu'à 2,6 fois plus vite dans certains cas.

2. L'astuce « Un-à-Plusieurs »
Parfois, une seule boîte contient plusieurs petits objets à l'intérieur.

L'Ancienne Façon : Le Contremaître prendrait la boîte, l'ouvrirait, en sortirait un objet, le mettrait dans un tas, retournerait, en sortirait le suivant, et répéterait.
La Nouvelle Façon : Les auteurs ont trouvé un outil spécial (appelé mapMulti) qui permet au Contremaître d'ouvrir la boîte et de déverser tous les objets d'un coup, d'un seul mouvement fluide.
Le Résultat : Cela s'est révélé encore plus efficace que le premier conseil, doublant souvent la vitesse.

3. Le Puzzle du Parallélisme (Utilisation de nombreux ouvriers)
Lorsque vous avez un immense entrepôt, vous voulez utiliser de nombreux ouvriers à la fois (traitement parallèle). Le papier a testé quatre façons différentes d'organiser ces ouvriers :

L'Équipe « Ordre Strict » : Tout le monde travaille en file, passant les boîtes. Bon pour maintenir l'ordre, mais lent.
L'Équipe « Chaos » : Tout le monde attrape des boîtes au hasard. Rapide, mais difficile à gérer.
L'Équipe « Tableau Partagé » : Tout le monde écrit ses résultats sur un seul grand tableau blanc partagé.
L'Équipe « Atomique » : Tout le monde utilise un stylo spécial haute technologie qui ne bave jamais, même si deux personnes écrivent en même temps.

Le Verdict : Il n'y a pas d'équipe « meilleure » unique.

Si vous avez très peu de groupes d'articles à trier (comme trier seulement 4 types de fruits), les équipes « Ordre Strict » ou « Chaos » sont les plus rapides car le « Tableau Partagé » devient trop encombré (trop de disputes sur qui écrit en premier).
Si vous avez des milliers de groupes (comme trier 10 000 types de fruits différents), l'équipe « Tableau Partagé » gagne car les disputes cessent, et chacun peut écrire sa propre section sans heurter les autres.

4. L'Écart de Vitesse
La grande question : le « Contremaître » (Stream) est-il plus lent que le « Manager » (Impératif) ?

Oui. Le code traditionnel « Manager » est constamment plus rapide, généralement d'environ 30 % à 40 %.
Pourquoi ? Le « Contremaître » doit passer du temps à traduire votre note élégante en actions. Le « Manager » fait simplement le travail immédiatement.
La Bonne Nouvelle : L'écart n'est pas aussi énorme que les gens le pensaient dans le passé. L'équipe Java a amélioré le moteur. Cependant, pour des performances absolument maximales, le style « Manager » gagne toujours.

5. Le Compromis : Vitesse vs Sanity
Le papier a également examiné la difficulté de lecture du code.

Le code « Manager » (le plus rapide) ressemble à un manuel d'instructions dense et confus. Il est difficile à lire et facile de faire des erreurs.
Le code « Contremaître » (plus lent) ressemble à une histoire claire et courte. Il est beaucoup plus facile à comprendre et moins susceptible de contenir des erreurs.
La Leçon : Vous devez choisir. Voulez-vous que le code s'exécute 30 % plus vite, ou voulez-vous qu'il soit 2,5 fois plus facile pour les humains à lire et à maintenir ? Le papier suggère que pour la plupart des gens, le style « Contremaître » vaut la petite pénalité de vitesse car il économise du temps sur le débogage et la maintenance.

Résumé

JEDI est un nouvel outil qui aide les développeurs à comprendre le « coût » de l'utilisation de l'API Stream Java moderne et facile à lire. Il prouve que bien que le code facile à lire soit légèrement plus lent que le code à l'ancienne, vous pouvez le rendre beaucoup plus rapide en utilisant des astuces spécifiques (comme la combinaison de filtres). Il indique également aux développeurs exactement comment organiser leurs ouvriers (stratégies parallèles) en fonction de la quantité de données qu'ils ont. En fin de compte, il offre aux développeurs une feuille de route pour écrire du code à la fois lisible et raisonnablement rapide.

Résumé technique : JEDI – Évaluation Java des requêtes déclaratives et impératives

Énoncé du problème

L'API Java Stream, introduite dans Java 8, offre une syntaxe déclarative pour le traitement des collections et des sources de données infinies, visant à améliorer la productivité des développeurs, la lisibilité du code et sa maintenabilité par rapport au code impératif traditionnel basé sur les boucles. Bien que l'API simplifie le calcul parallèle grâce à des abstractions de haut niveau, la littérature existante indique que les implémentations basées sur Stream souffrent souvent de pénalités de performance par rapport à du code impératif équivalent.

Une lacune critique identifiée dans ce travail est l'absence de suites de benchmarks dédiées à l'API Stream. Sans de tels benchmarks, il est difficile pour :

Les chercheurs et les développeurs de bibliothèques : d'optimiser l'implémentation de l'API Stream au sein de la bibliothèque de classes Java (JCL).
Les développeurs d'applications : de comprendre les caractéristiques de performance des différentes opérations de flux et stratégies de parallélisation afin d'écrire du code efficace.

Les benchmarks actuels ne ciblent pas explicitement l'API Stream ou reposent sur des pipelines synthétiques simples qui ne reflètent pas des charges de travail de traitement de données complexes et réelles.

Méthodologie

Pour combler cette lacune, les auteurs présentent JEDI (Java Evaluation of Declarative and Imperative Queries), une suite de benchmarks générée automatiquement en convertissant des requêtes SQL en code source Java.

Processus de génération

Matériel source : Les auteurs utilisent le benchmark TPC-H, un benchmark d'analyse de données largement utilisé composé de requêtes complexes couvrant diverses fonctionnalités de traitement de données (jointures, agrégations, filtrage, tri).
Conversion de code : Les auteurs ont étendu un outil existant, S2S (SQL to Stream), pour convertir des requêtes SQL en plusieurs implémentations Java sémantiquement équivalentes.
- Mappage du schéma : Les tables SQL sont mappées vers des tableaux en mémoire d'objets.
- Traduction des requêtes :
  - Projections SELECT $\rightarrow$ map(...)
  - Prédicats WHERE $\rightarrow$ filter(...)
  - ORDER BY $\rightarrow$ sorted(...)
  - LIMIT $\rightarrow$ limit(...)
  - GROUP BY et agrégations $\rightarrow$ collect(...) avec des collecteurs générés.
  - JOIN $\rightarrow$ Implémenté via flatMap (construction d'une table de hachage pour le côté build) ou mapMulti.
Variantes d'implémentation : Pour une seule requête SQL, JEDI génère plusieurs variantes afin de comparer différents modèles de codage et stratégies d'exécution :
- Variantes séquentielles :
  - O1 (Fusion de filtres) : Combinaison de plusieurs prédicats en un seul appel filter versus plusieurs appels chaînés.
  - O2 (Implémentation de jointure) : Utilisation de mapMulti versus flatMap pour les opérations de jointure.
- Variantes parallèles (O3) :
  - P : Flux parallèles ordonnés (parallel()).
  - PU : Flux parallèles non ordonnés (parallel().unordered()).
  - CG : Flux parallèles non ordonnés utilisant groupingByConcurrent (état partagé avec synchronisation basée sur des verrous).
  - CGCC : CG avec collecteurs aval thread-safe (opérations atomiques sans verrou).
- Base impérative : Une implémentation basée sur des boucles utilisant exactement les mêmes structures de données et ordre d'opérations que les versions de flux pour mesurer la « surcharge de l'API Stream ».

Configuration d'évaluation

Matériel : Deux architectures distinctes : Intel Xeon Gold (16 cœurs) et ARM Neoverse-N1 (80 cœurs).
JVM : Oracle JDK 24 et GraalVM 24.
Ensembles de données : Facteurs d'échelle TPC-H de 1 (1 Go) pour l'analyse séquentielle et 10 (10 Go) pour l'analyse parallèle.
Outils : Java Microbenchmark Harness (JMH) avec des itérations de chauffe et mesurées pour garantir une performance à l'état stable.

Contributions clés

Suite de benchmarks JEDI : La publication d'une suite de benchmarks open source dérivée de TPC-H, générant automatiquement des implémentations de flux et impératives sémantiquement équivalentes.
Générateur de code : Une version étendue de S2S prenant en charge plusieurs stratégies d'implémentation (optimisations séquentielles et divers modèles de réduction parallèle).
Directives de performance : Un ensemble de bonnes pratiques dérivées pour utiliser l'API Stream efficacement, basées sur des données empiriques.
Analyse de la surcharge : Une comparaison directe du code basé sur les flux versus le code impératif utilisant des structures de données et des ordres d'opérations identiques pour isoler le coût de performance des abstractions de l'API.

Résultats et constats

RQ1 : Optimisations séquentielles (Fusion de filtres et implémentation de jointure)

Fusion de filtres (O1) : La combinaison de prédicats en un seul appel filter améliore les performances, en particulier lorsque de nombreux prédicats sont présents (par exemple, une accélération de 3,54 fois sur un micro-benchmark avec 7 prédicats).
Implémentation de jointure (O2) : L'utilisation de mapMulti plutôt que flatMap pour les jointures apporte des améliorations significatives (accélération géométrique moyenne de 1,38 fois sur Intel JDK).
Conclusion : Les développeurs devraient appliquer à la fois O1 et O2 chaque fois que possible.

RQ2 : Stratégies de parallélisation

Aucun gagnant universel : Aucune stratégie parallèle unique ne domine tous les scénarios. Les performances dépendent fortement des caractéristiques des données, notamment du nombre de groupes agrégés et de la nature de l'agrégation.
Agrégations scalaires versus groupées :
- Pour les agrégations scalaires (sans regroupement) ou un petit nombre de groupes, les flux parallèles ordonnés (P) ou non ordonnés (PU) surpassent les stratégies d'état partagé (CG, CGCC) en raison d'une moindre contention.
- Pour les agrégations groupées avec un grand nombre de groupes, CG (utilisant groupingByConcurrent) est généralement la meilleure stratégie. À mesure que le nombre de groupes augmente, la contention des verrous diminue, rendant la synchronisation basée sur des verrous efficace.
Sans verrou versus avec verrou : CGCC (sans verrou) ne surpasse pas systématiquement CG (avec verrou) et introduit une complexité d'implémentation. Cependant, CGCC est plus robuste pour des très petits nombres de groupes où CG souffre d'une forte contention.
Opérations distinct : Bien que les flux non ordonnés (PU) soient généralement recommandés pour distinct, l'étude a révélé que pour des flux avec un faible nombre d'éléments distincts, les flux parallèles ordonnés (P) peuvent être jusqu'à 2 fois plus rapides en raison de la surcharge de gestion d'un ConcurrentHashMap partagé dans les flux non ordonnés.

RQ3 : Performance des flux versus impératif

Supériorité impérative : Le code impératif basé sur des boucles surpasse systématiquement le code basé sur les flux.
Ampleur : L'accélération géométrique moyenne du code impératif par rapport à la meilleure implémentation de flux séquentielle varie de 1,28x à 1,41x selon les différentes JVM et architectures.
Contexte : Bien que cela confirme les résultats précédents, les auteurs notent que l'écart est plus faible que dans certaines études antérieures, suggérant des améliorations de l'implémentation de l'API Stream au fil du temps. Cependant, pour le code critique en termes de performance, le code impératif reste substantiellement plus rapide.

RQ4 : Complexité du code

Lisibilité : Malgré l'écart de performance, le code basé sur les flux présente des métriques de complexité significativement plus faibles.
Métriques : La complexité cognitive du code de flux de base est 2,43 fois inférieure à celle du code impératif. Même avec des optimisations (O1+O2), le code de flux reste 1,62 fois moins complexe que le code impératif.
Compromis : L'optimisation du code de flux (par exemple, fusionner des filtres) augmente ses métriques de complexité mais le maintient en dessous de la complexité des équivalents impératifs.

Importance et affirmations

L'article positionne JEDI comme un outil vital pour la communauté Java et les implémenteurs de JVM :

Pour les développeurs : Il fournit des directives basées sur des données pour minimiser la surcharge de performance de l'API Stream, suggérant des modèles spécifiques (par exemple, mapMulti, groupingByConcurrent pour les grands groupes) en fonction des caractéristiques de la charge de travail.
Pour les implémenteurs de bibliothèques : La suite de benchmarks et la « surcharge » identifiée fournissent une référence pour optimiser l'implémentation de l'API Stream afin de réduire l'écart de performance avec le code impératif.
Pour les chercheurs : Il offre une charge de travail complexe et reproductible (dérivée de TPC-H) pour évaluer les futures optimisations, les outils de refactorisation ou les stratégies de parallélisation.

Les auteurs reconnaissent modestement les limites, notant que JEDI se concentre actuellement sur des sources de données basées sur des tableaux et des modèles spécifiques de traduction SQL-Stream. Ils prévoient d'étendre le générateur pour couvrir davantage de méthodes de l'API Stream et varier les sources de données (par exemple, Listes, Ensembles) dans des travaux futurs.