perf: route PostToolUse hooks by handled tool names (W2-1b) - #483
Merged
Merged
Conversation
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
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.
Symptôme
W2-1 / F2, seconde PR : chaque appel d'outil lance quatre processus Python,
alors que trois des hooks ne traitent que des noms d'outils déterminés.
PR empilée sur #482.
Cause racine
Un groupe PostToolUse sans matcher regroupait les quatre commandes. Les
gardes Python évitaient le traitement mais payaient le lancement et les imports.
Changement
Quatre groupes déclarent les outils réellement traités : capture
*,preemptive
Edit|Write|Read, pipelineEdit|Write|MultiEdit, reindexBash.Les commandes et timeouts sont inchangés. Capture reste sur
*pour conserverla cadence globale réparée ensuite dans W2-4. Source :
Claude Code — matchers de hooks.
L'agrégateur stdlib valide les mesures contre chaque manifeste réel, refuse
les processus manquants/doublons/échecs ou le mélange launcher/module, et
conserve les quatre répétitions en excluant la première.
Preuve
Base
1f4196ef20ee0c52c18990924a2c3d1be80a76bf. Même code des hooks avant/après,seul le routage diffère ; aucun rebase après mesure. Python 3.13.7, macOS ARM64,
10 cœurs. Dépendances préparées hors mesure ; modèle existant en cache, réseau
ML désactivé ; SQLite jetable et DSN PostgreSQL vers socket inexistant.
Chaque mesure est
/usr/bin/time -l -o <log> <python> scripts/launcher.py <hook>avec le même JSON. Quatre répétitions, première exclue, traces d'import séparées.
Les Read mesurés sont rejetés par la porte (novelty 0.113, threshold 0.4), les Bash
sont capturés ; aucune erreur masquée à la place d'une capture. Les six lignes
résultantes portent
embedding_model=neural; ids, contenus et vecteurs sontstrictement identiques entre les deux bases isolées, vérifiés en lecture seule.
Preuve :
/private/tmp/cortex-green-w2-1b-neural-proof.json.Les deux processus inutiles sont supprimés pour chaque payload. Le coût total
reste dominé par la capture (2,73–3,08 s CPU dans les échantillons après,
RSS maximal 492847104 octets). L'objectif cumulé ≤0,15 s n'est pas atteint.
Un dispatcher seul ne supprimerait pas l'inférence froide dans la capture ;
W3-1 traite ce coût. Aucune accélération globale n'est revendiquée pour Bash
(médiane 2,91→2,92 s) ; les imports/lancements évités sont la preuve locale.
Les sommes wall séquentielles sont conservées dans le rapport, sans être
présentées comme latence Claude, qui peut lancer ses hooks en parallèle.
Avant : charge 3,97→3,66 / 10 ; après 4,29→4,05 / 10 ; disque 61 GiB avant/après.
Les valeurs de BSD time sont publiées avec la précision de ses journaux.
13 tests ciblés passent : routage de tous les outils, commandes/timeouts,
payloads identiques, parser de mesures réelles, règles d'agrégation et refus
explicites. Gates locaux ordonnés, code final 0 : Ruff/format 1 420 fichiers,
craftsmanship, Pyright zéro diagnostic ; hooks+scripts 1 134 passed,
17 skipped, 292 subtests en 23,70 s ; suite complète 7 606 passed,
221 skipped, 292 subtests en 140,07 s. Skips PG explicites, aucun accès production.
Journal :
/private/tmp/cortex-green-w2-1b-gates.log; charge initiale 3,92 / 10,disque 61 GiB avant/après. Le driver suit les sync/extras/groupes, Ruff,
craftsmanship, Pyright et pytest dans l'ordre du contrat.
SHA final
7ea80be4cbcbc8c0f54e5e2a2693c811a0a2e4a9. CI externe 34044438025 terminée verte sur ce SHA.Conformité
Trois fichiers concernés, dont deux nouveaux fichiers Python sous 300 lignes,
fonctions sous 40 lignes/quatre paramètres ; baseline inchangée. Aucun import
mémoire ou algorithme modifié, aucune constante de performance inventée.
Un seul travail lourd local à la fois, données et dépendances de mesure privées.
Candidats issues
Le coût froid de la capture empêche le plancher cumulé visé ; il est traité en
W3-1, pas caché par un payload qui ne capture rien. Aucun nouveau ticket.
L'environnement de mesure avec PG indisponible ne mesure pas les scans d'une
base chargée ; ceux-ci relèvent des items cooldown/requêtes dédiés.
Runbook
Aucune opération de données. Le propriétaire décide de la fusion ; la capture
reste active sur tous les outils selon ses règles existantes.