Un paquet de démonstration : l'outil ET l'application qu'il observe - #53
Merged
Conversation
Le kit hors ligne porte l'outil vers une application qu'on a déjà. Celui-ci porte une application AUSSI — sample-app.jar, ses dépendances et ses sources — pour qu'on puisse rejouer la campagne publiée avec un JDK et rien d'autre, sans construire le dépôt et sans réseau : l'édition complète dépose ses cinq composants dans ~/.runtime-xray au premier lancement. Deux décisions ont été prises en l'exécutant, pas en le lisant, et les deux auraient livré un paquet qui démontre le contraire de ce pour quoi il existe. --classes ne nomme que sample-app.jar. Ajouter libs/commons-lang3.jar — que l'application atteint vraiment, et que la démo publiée passait vraiment — met ses 231 classes dans la couverture, dont aucune n'a sa source dans le paquet. Le rapport s'ouvrait sur « 231 classes mesurées sur 258 n'ont pas leur source » : exactement le mode de défaillance que cet outil existe pour expliquer, sur le premier écran d'une démonstration. --attach-after se calcule sur la charge. Les valeurs se capturent en s'attachant à la JVM vivante, et les 8 s par défaut ne conviennent qu'à la charge complète. Raccourcir la campagne — ce que le README propose — faisait finir l'application avant l'attachement, et un tiers de ce que montre le rapport disparaissait avec un avertissement que personne n'aurait relié au ITERATIONS= qu'il venait de taper. Le README dit aussi ce qu'on ne verra pas sous Windows, et que c'est la plateforme et non le paquet : async-profiler n'y publie aucun binaire. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J956wjynbd7fkZx4HpjHzP
Mesuré en exécutant le paquet, pas en le lisant. Les trois runs observés de la même façon : RoutePlanner::travelTimeMinutes 8 M itérations → 31 s RoutePlanner::travelTimeMinutes 24 M itérations → 206 s Terrain::slowdownFactor 24 M itérations → coupé à 600 s Terrain::slowdownFactor est appelée plusieurs fois par itinéraire là où l'autre l'est une seule fois, et capturer les valeurs veut dire tracer CHAQUE invocation. Donner le même nombre d'itérations aux trois runs — ce que fait la démonstration publiée — rend le deuxième dix fois plus long que les autres, et ici l'outil a dû l'arrêter : « stopped after 600 s (safety limit) ». Un paquet de démonstration dont le run du milieu se fait tuer démontre le garde-fou. Chaque run est donc dimensionné pour sa propre racine, à partir d'un WORKLOAD unique : /4 pour le premier, /8 pour celui qui trace la méthode chaude, entier pour le dernier. La forme de la campagne ne bouge pas — trois exécutions, trois racines, trois filtres — seul le nombre d'échantillons derrière les pourcentages. Le même test a par ailleurs prouvé le chemin embarqué, jamais exercé ici puisque le dépôt Maven local le précède : avec ~/.runtime-xray vide et MAVEN_REPO_LOCAL sur un répertoire vide, les cinq composants sortent du jar complet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J956wjynbd7fkZx4HpjHzP
Le correctif précédent dimensionnait le run du milieu à WORKLOAD/8 pour ne plus franchir le garde-fou. Il ne le franchissait plus, et ne récoltait plus que 64 échantillons : un arbre qui ne montre rien, ce qui remplace un défaut par un autre. Les points mesurés sur Terrain::slowdownFactor, tous observés pareil : 1 M → 4 s, 64 mesures 4 M → 24 s, 279 mesures 2 M → 5 s, 116 mesures 24 M → coupé à 600 s Au-delà de 4 M, allonger le run n'achète presque plus d'échantillons : le temps part dans le traçage, qui n'est pas dans lab/sample/terrain/* et ne compte donc pas. C'est précisément ce que ce run est là pour montrer — ce que fait un filtre étroit — donc le prolonger n'aurait rien démontré de plus. D'où la moitié du WORKLOAD pour les deux premiers runs et le WORKLOAD entier pour le dernier : moins de deux minutes en tout. La démo publiée donne 24 M aux trois et paie onze minutes, sur la machine où elle a été enregistrée ; le README dit comment s'en rapprocher pour qui veut attendre. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J956wjynbd7fkZx4HpjHzP
Beennnn
marked this pull request as ready for review
September 7, 2026 06:32
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
bin/demo-kit.shassemble un zip qui rejoue la campagne publiée sur n'importe quelle machine ayant un JDK 21, sans construire le dépôt et sans réseau.Ce que ça porte
runtime-xray.jar~/.runtime-xrayau premier lancementsample-app.jar+libs/src/demo.sh,demo.cmdREADME.txt,SHA256SUMS.txtLa différence avec
bin/offline-kit.shest le point : celui-là porte l'outil vers une application qu'on a déjà, celui-ci porte une application aussi.Deux décisions prises en l'exécutant, pas en le lisant
Les deux auraient livré un paquet qui démontre le contraire de ce pour quoi il existe.
--classesne nomme quesample-app.jar. Ajouterlibs/commons-lang3.jar— que l'application atteint vraiment, et que la démo publiée passait vraiment — met ses 231 classes dans la couverture, dont aucune n'a sa source dans le paquet. Le rapport s'ouvrait sur :Exactement le mode de défaillance que cet outil existe pour expliquer, sur le premier écran d'une démonstration.
--attach-afterse calcule sur la charge. Les valeurs se capturent en s'attachant à la JVM vivante, et les 8 s par défaut ne conviennent qu'à la charge complète. Raccourcir la campagne — ce que le README propose — faisait finir l'application avant l'attachement :Un tiers de ce que montre le rapport disparaissait, avec un avertissement que personne n'aurait relié au
ITERATIONS=qu'il venait de taper.Vérification
Testé comme le ferait quelqu'un qui reçoit le zip : décompressé ailleurs,
~/.runtime-xrayvidé etMAVEN_REPO_LOCALpointé sur un répertoire vide. Le jar complet a déposé ses cinq composants tout seul — c'est le chemin embarqué, celui qui n'était jamais exercé ici puisque le dépôt Maven local le précède.Le
README.txtdu paquet dit aussi ce qu'on ne verra pas sous Windows, et que c'est la plateforme et non le paquet : async-profiler n'y publie aucun binaire, la couverture et les valeurs marchent identiquement, et le rapport le dit maintenant là où l'arbre serait.🤖 Generated with Claude Code
https://claude.ai/code/session_01J956wjynbd7fkZx4HpjHzP
Generated by Claude Code