Optimisation de l'analyse REA
Trouvez une source concrète de travail inutile, modifiez-la chez son propriétaire et vérifiez que les investigations terminées restent équivalentes. Un résultat utile peut aussi être une décision mesurée de laisser une implémentation inchangée.
Suivez les priorités de performance du checkout, la conception des outils et le guide de test. Cette compétence fournit un workflow d'optimisation, pas une autorisation supplémentaire pour exécuter des cibles, publier ou fusionner. Utilisez les contrats en cours, les prérequis des fournisseurs et l'autorisation de l'utilisateur.
Réservez les mesures de performance aux modifications qui ciblent la performance ou qui présentent un risque concret de régression. Le nettoyage de routine utilise des vérifications d'exactitude et ne nécessite pas ce workflow d'optimisation ni des benchmarks synthétiques simplement parce que les appels auxiliaires, les importations ou les représentations changent.
Lisez l'étude de cas Kuna lors du choix d'une stratégie de réutilisation ou de l'interprétation d'un benchmark. Ses observations consolidées illustrent des compromis ; elles ne constituent ni des garanties du fournisseur actuel ni des accélérations universelles.
Définir la question et l'oracle d'exactitude
Décrivez la tâche terminée de l'analyste, y compris les faits et relations nécessaires pour y répondre, le niveau de détail demandé, l'accès aux sources et les inconnues significatives. Choisissez un artefact réel représentatif et un cas petit ou vide. Enregistrez la révision de référence, le digest cible, l'identité du moteur, les options, l'hôte et le point d'entrée. Utilisez un checkout séparé pour les modifications sans perturber les autres travaux.
Établissez un oracle indépendant de l'implémentation modifiée : attentes de fixtures construites à partir des sources, octets de fichier mappés indépendamment, ou un producteur natif associé à des vérifications de son interprétation. Comparer deux wrappers autour du même décodeur défectueux n'établit pas l'exactitude. Préservez les largeurs d'adresse, les alternatives à la même adresse, les points d'extrémité non résolus, la couverture et le lien source. Un résultat vide prouve l'absence uniquement dans le périmètre réellement examiné.
Localiser le travail inutile le plus précoce
Tracez une tâche publique CLI ou MCP à travers le code d'application partagé jusqu'à son producteur. Mesurez les phases pertinentes : vérifications d'admission et d'identité, analyse native, décodage, recherche, projection, sérialisation, conservation des preuves et nettoyage. Incluez la découverte de catalogue et les appels supplémentaires lorsqu'ils affectent la tâche terminée.
Utilisez les preuves pour choisir la correction structurelle la plus petite :
| Coût observé | Correction candidate | Condition à établir |
|---|---|---|
| Analyses répétées de faits validés | Réutiliser la structure d'ordre ou de recherche existante | Le propriétaire établit l'ordre et l'identité ; chaque alternative correspondante survit |
| Travail moteur équivalent répété | Partager un résultat validé ou un producteur en cours | Les entrées, la fraîcheur, la durée de vie et les résultats par appelant restent explicites |
| Rapports complets pour des faits sélectionnés | Pousser la sélection ou la projection vers le propriétaire capable le plus précoce | Les faits requis et les preuves restent accessibles ; la couverture examinée est rapportée |
| Grands tampons de transport temporaires | Décoder de manière incrémentale ou utiliser des lectures source bornées | Valider l'ensemble du document admis ; les faits retenus et les copies consomment toujours de la mémoire |
| Nombreuses lectures homogènes répétées | Partager l'admission, le décodage ou le travail par lot | Préserver l'identité des éléments, l'ordre si requis et les échecs individuels |
N'introduisez pas d'index, de cache générique, de point d'extrémité par lot ou de couche d'orchestration sans identifier le travail qu'il supprime et son coût de maintenance/ressources. La projection après matérialisation d'un rapport complet peut réduire la sortie tout en laissant inchangés le temps d'analyse et le pic de mémoire. Corrigez les faits manquants ou incorrects avant de comparer une composition alternative à un workflow mieux couvert.
Conserver une seule interprétation et une durée de vie de réutilisation définie
Laissez la frontière du producteur valider et normaliser les faits une seule fois. Les consommateurs interrogent cette représentation via l'implémentation CLI/MCP partagée ; les adaptateurs ne doivent pas reconstruire les relations ni réinterpréter indépendamment les rapports bruts. Séparez l'identité de recherche du format d'affichage. Réutilisez les contrats lorsque leur intention correspond, en honorant le niveau de détail demandé et l'accès complet aux preuves.
Pour chaque cache ou producteur partagé, indiquez sa clé, son propriétaire, son invalidation, sa taille retenue et sa durée de vie. Tenez compte des octets cibles affectant le résultat, du contenu du moteur, des options d'analyse, du mappage architecture/charge, et des versions de parseur/schéma lorsqu'ils affectent la réutilisation. Validez l'état en direct avant de considérer une observation mise en cache comme actuelle. Ne mettez en cache un refus que s'il est déterministe pour cette clé validée ; les tentatives malformées, partielles, transitoires ou annulées nécessitent une politique de nouvelle tentative explicite.
Un attente annulée ne doit pas invalider un pair réussi. Préservez le contexte d'échec du producteur et la raison d'annulation de chaque appelant. Conservez la propriété et les charges de capacité jusqu'à ce que le travail partagé et le nettoyage soient terminés ; préservez les observations terminées lorsque le nettoyage échoue. Exercez l'invalidation, les consommateurs concurrents, l'annulation du dernier attente, la fermeture et la nouvelle tentative de nettoyage lorsque ces chemins changent.
Limitez la famille de processus et l'état retenu, pas seulement un heap parent ou un nombre de workers. Tenez compte de l'expansion de décodage et de sérialisation avant l'allocation. Choisissez les limites de CPU, mémoire, concurrence et disque à partir de l'hôte et de la charge de travail ; arrêtez-vous avant une OOM et vérifiez le nettoyage propriétaire. Une tâche arrêtée par une garde est incomplète. Ne remplacez pas une limite de tampon de transport par un inventaire retenu illimité, ni ne cachez des résultats partiels derrière un statut de succès.
Comparer les tâches terminées et limiter la revendication
Exécutez le workflow public réel affecté avant et après avec des entrées, des résultats, une couverture et des sémantiques de preuves équivalents. Incluez de petites entrées pour que les coûts de configuration et les régressions soient visibles. Distinguez les sessions fraîches, les caches d'exécution chauds et les caches de fichiers OS. Alternez ou répétez les exécutions lorsque la variance affecte la décision. Choisissez des régressions de frontière significatives pour les cas que le moteur réel ne peut pas reproduire de manière fiable ; un faux moteur ne qualifie pas un fournisseur réel.
Rapportez le résultat de la tâche, les temps de phase pertinents, le temps total écoulé et CPU, le pic de mémoire de la famille de processus et sa méthode de comptabilité, les arrêts de ressources et le nettoyage. Vérifiez le statut de sortie du payload ainsi que celui du profileur. Conservez les tentatives échouées et identifiez les coûts non mesurés ; une nouvelle tentative réussie n'explique pas un échec.
Pour les revendications de tokens, comptez les schémas/découverte, les arguments, les réponses, les nouvelles tentatives et les continuations nécessaires pour terminer la tâche. Étiquetez les estimations de tokenizer séparément de l'utilisation réelle du modèle et enregistrez le comportement client/catalogue. Un seul JSON plus petit n'établit ni moins de tokens de modèle ni une meilleure qualité d'investigation. Ne revendiquez pas un avantage de logiciel complexe sans investigations terminées représentatives et une exactitude/couverture comparable.
Terminez avec le goulot d'étranglement, la modification propriétaire, les sémantiques préservées, les vérifications exécutées, les mesures avant/après et les limites restantes. Gardez tout enregistrement d'intégration à jour avec sa révision testée et distinguez le travail de production fusionné du code expérimental seul. Arrêtez-vous lorsque le goulot d'étranglement démontré est résolu ou que les avantages supplémentaires restent spéculatifs.