Nous travaillons sur une base de code C ++ de taille moyenne (10Mloc) qui, grâce à nos efforts d'optimisation, devient uniformément lente .
Cette base de code est un ensemble de bibliothèques que nous combinons pour les mettre au travail. Lorsque le cadre général de la façon dont ces bibliothèques communiquent a été développé, l'accent a été mis sur les performances et plus tard, lorsque davantage de parties ont été ajoutées, le cadre général n'a pas beaucoup changé. L'optimisation a été effectuée en cas de besoin et à mesure que notre matériel évoluait. Cela a rendu la décision précoce coûteuse apparente seulement beaucoup plus tard. Nous sommes maintenant à un point où de nouvelles optimisations sont beaucoup plus coûteuses car elles nécessiteraient la réécriture de grandes parties de la base de code. Nous nous trouvons à l'approche d'un minimum local indésirable car nous savons qu'en principe le code devrait pouvoir s'exécuter beaucoup plus rapidement.
Existe-t-il des méthodologies réussies qui aident à décider des virages pour prendre en charge l'évolution d'une base de code vers une solution globale et optimisée qui ne soit pas facilement confondue par des opportunités d'optimisation faciles?
ÉDITER
Pour répondre à la question de savoir comment nous profilons actuellement:
Nous n'avons vraiment que 2 scénarios différents sur la façon dont ce code peut être utilisé, tous deux parallèlement embarrassants. Le profilage se fait à la fois avec une horloge murale moyenne sur un grand échantillon d'entrées et des exécutions plus détaillées (coûts d'instruction, erreurs de prédiction de branche et problèmes de mise en cache). Cela fonctionne bien puisque nous fonctionnons exclusivement sur nos machines extrêmement homogènes (un cluster de quelques milliers de machines identiques). Comme nous gardons généralement toutes nos machines occupées la plupart du temps plus rapidement, nous pouvons examiner de nouvelles choses supplémentaires. Le problème est bien sûr que lorsque de nouvelles variations d'entrée apparaissent, elles peuvent être pénalisées pour retard dans la mesure où nous avons supprimé les micro-inefficacités les plus évidentes pour les autres cas d'utilisation, réduisant ainsi éventuellement le nombre de scénarios "fonctionnant de manière optimale".
sloc
. Je l'ai appelé "de taille moyenne" parce que je n'ai aucune idée de ce qui est considéré comme "gros" ici.