Vous favorisez une période de temps où tout le monde peut essayer des idées pour accélérer l'exécution des logiciels?

Parfois, les astuces de performance des logiciels sont trouvées à partir d'une recherche méthodologique et approfondie. Parfois, il faut une pensée divergente et du courage pour essayer des idées folles. Parfois, une idée n'est que le début qui doit être suivie avec beaucoup de travail acharné.

Comment favoriser une période de temps où chacun peut essayer différentes idées pour améliorer les performances du logiciel sur lequel nous travaillons? Tout le monde dans l'équipe a au moins plusieurs mois d'expérience avec le logiciel et est très bon dans ce domaine.

Êtes-vous d'accord sur le fait qu'une pensée divergente aidera à trouver des moyens d'améliorer les performances des logiciels? Pourquoi? Pourquoi pas?

Quelles techniques nous permettront de tester rapidement une idée d'optimisation? Une vitesse de codage rapide est-elle nécessaire pour obtenir de bons résultats de l'essai?

Enfin, combien de "temps" devrait être alloué pour garantir de bons résultats sans créer de possibilité de relâchement?

L'expérimentation est-elle nécessaire pour prouver qu'il existe "un moyen plus rapide de faire quelque chose"? (Ajouté le 2011-06-07)

En relation:

• Quelles sont vos stratégies pour améliorer le niveau de votre équipe de manière intelligente?
• Quand les hacks de code deviennent-ils mauvais?

( À des fins de prime uniquement -2011/06/07, la taille de l'équipe est de 2 à 4 développeurs, aucun contrôle qualité dédié. Tous les codes, tests unitaires et tests de performances effectués par les développeurs. En raison de la nature du projet, le résultat du profileur est utile pour montrer temps d'exécution proportionnel même s'il ne révèle aucun goulot d'étranglement.)

Votre meilleur pari est d'identifier les hotspots avec un profileur et - en équipe - de discuter de la façon de réparer les hotspots.

Vous devez être en mesure de mesurer et de documenter l'amélioration (il ne s'agit donc pas seulement de deviner de façon extravagante) et de le faire en équipe pour vous assurer que les gens savent ce qui est corrigé et comment.

Le fait que les programmeurs piratent énormément la base de code en essayant des idées signifie que vous n'avez aucun contrôle sur ce qui se passe et si cela fonctionne.

Les programmeurs ont tendance à être intelligents et créatifs (car ce sont des conditions préalables pour être bon en programmation), il est donc toujours bon de les laisser essayer un large éventail d'idées lorsqu'ils essaient de résoudre des problèmes. Il y a cependant deux choses qui sont importantes à retenir lorsque vous tentez d'améliorer les performances (je suppose qu'avec "performances" vous entendez réduire la vitesse d'exécution):

• Les optimisations algorithmiques ont tendance à fonctionner beaucoup mieux qu'autre chose. À titre d'exemple trivial, quoi que vous fassiez à votre implémentation de bullesort, avec des nombres suffisants, une implémentation extrêmement lente de quicksort sera finalement plus rapide.
• Faire quoi que ce soit lié aux performances est complètement absurde à moins que vous ne mesuriez (profiliez) et basiez ce que vous faites sur les résultats.

Mon point principal est qu'il est important de s'assurer que vous êtes sur la même longueur d'onde avec tout le monde avant de commencer une période d' expérimentation sauvage . Il est toujours dommage de découvrir par la suite que vos collègues moins expérimentés essayaient des choses qui ne pourraient jamais fonctionner (et vous auriez pu leur dire cela dès le départ).

Malheureusement, je ne peux pas parler d'expérience. Mais j'ai entendu dire qu'Atlassian a une seule journée où les employés ont été autorisés à faire leur propre chose, tout ce qu'ils voulaient, et à présenter leurs idées dans une sorte d'atmosphère de fête. Cela s'est apparemment bien passé pour eux. Mais je dois être d'accord avec Andersen et dire qu'en matière de performance, les idées créatives et prêtes à l'emploi sont moins importantes que le profilage des processus qui prennent le plus de temps. Peut-être qu'une fois que vous aurez profilé votre système, vous pourriez donner à chacun une journée pour trouver des idées sur la façon d'accélérer des sections importantes du processus. Après avoir présenté leurs idées, vous pouvez choisir celles à essayer.

Une pratique réussie que nous avons faite sur certaines de mes équipes précédentes était d'avoir le concept de Deep Dives. Quelques personnes se réunissent dans une salle de conférence, déterminent un scénario utilisateur et commencent simplement à parcourir le code ou à consulter les journaux du profileur. Dans certains cas, les données ont clairement montré des goulots d'étranglement qui nous ont permis de convaincre les sceptiques qu'il y avait vraiment des problèmes de perf dans leur propre code! Pour réussir, nous avons suivi certains principes clés:

1. Essayez de vous concentrer sur les scénarios critiques ou les chemins de code où des goulots d'étranglement sont suspectés. Ne perdez pas de temps à optimiser des choses qui n'ont pas besoin d'être optimisées (si ce n'est pas cassé ...)
2. Gardez le groupe petit et concentré sur les personnes qui connaissent le mieux le code. N'oubliez pas d'inclure le testeur et le gestionnaire de programme de la fonctionnalité - ils ont des informations clés et peuvent bénéficier de la participation ou de la collecte d'informations sur la façon de mieux tester.
3. Commencez la session en demandant au propriétaire de la zone de fournir un diagramme de niveau bloc architectural de haut niveau et une vue d'ensemble de la zone. Quels sont les composants clés et décrivez brièvement ce qu'ils font. Vous serez surpris du nombre de fois où le diagramme n'a pas reflété la réalité une fois que nous avons creusé dans le code. (Citation réelle: "Je ne savais pas que nous utilisions toujours ce composant. Je pensais que nous nous étions débarrassés de cela il y a des années!")
4. Attendez-vous à trouver des bogues fonctionnels ainsi que des problèmes de performances. C'est une bonne chose. Aussi, attendez-vous à ce que, parfois, vous ne trouviez rien de significatif. Cela peut aussi être une bonne chose.
5. Attendez-vous à avoir plusieurs longues sessions. Ce sont des réunions de travail. Installez-vous confortablement et travaillez-y. Vous en faites beaucoup plus lorsque vous pouvez tous collaborer pour de longues périodes.
6. Prenez des notes, de bonnes notes. Si vous utilisez une base de données de suivi des défauts, envisagez d'ouvrir les problèmes immédiatement pour garder une trace, même s'ils sont de faible priorité.

Évitez de faire participer toute l'équipe à une «poussée de performance». Ceux-ci n'ont généralement pas les résultats attendus par la direction pour les raisons mentionnées par Thorbjørn Ravn Andersen dans une autre réponse. Vous obtiendrez de grands gains dans certains domaines, des régressions dans d'autres domaines où les gens ne sont pas familiers, et il est difficile de prédire / suivre les gains que vous devriez obtenir pour dire «vous avez terminé». C'est une conversation difficile à avoir avec la direction.

La raison pour laquelle vous devrez peut-être améliorer la vitesse de votre logiciel est si quelque chose est sensiblement lent. Si ce n'est pas le cas, l'optimisation est une perte de temps. Mais si quelque chose est lent, alors faites la tâche.

... Et pour faire la tâche, il y a deux étapes dans cet ordre:

1. Vérifiez si la fonction qui effectue la tâche est correctement écrite. A-t-il un bon ou un mauvais algorithme? Accède-t-il à une base de données de manière efficace? Est-il en boucle 100 fois quand une seule fois peut le faire? Souvent, une simple inspection du code peut trouver le seul obstacle et non seulement le résoudre, mais aussi faire de vous un meilleur programmeur.

2. Ne passez pas plus d'une heure ou plus sur le numéro 1. Si vous ne trouvez pas le problème en une heure, utilisez un profileur pour trouver l'endroit en question. Une fois que vous connaissez le problème, vous pouvez revenir au numéro 1 et recommencer, en essayant de trouver la meilleure façon d'améliorer le code que vous avez identifié.

En général (**) vous n'obtenez pas de meilleures performances par expérimentation.

Vous l'obtenez par

• Savoir faire un design simple et efficace pour commencer. Si vous vous trompez cette partie, l'expérimentation ne fera pas beaucoup de différence. Par exemple, savoir comment utiliser un générateur de code est une approche de conception gagnante.

• Savoir régler un logiciel en localisant les activités qui sont a) coûteuses en pourcentage et b) remplaçables par quelque chose de mieux. Tout le monde sait que vous devez "utiliser un profileur", mais cela ne suffit pas.

Vérifiez cette réponse à votre autre question.

** Les exceptions peuvent être du code strict dépendant du matériel, comme le rendu graphique, le pipeline de processeur ou le comportement CUDA, ou l'expérimentation de protocoles réseau ou DB, où il vous suffit de vous familiariser avec la meilleure façon de l'utiliser.

AJOUT: Il y a quelque chose que de nombreux programmeurs de grands systèmes trouvent surprenant. C'est que dans les grands programmes parfaitement bien construits, il peut y avoir de gros problèmes de performances invisibles , et les profileurs ne peuvent pas les trouver car ils ne sont pas localisés dans les routines. Ils font partie de la structure générale du programme, même si le programme peut être réalisé dans le meilleur style.

Juste pour donner un exemple concret, voici un programme avec du code source (en C ++) qui fait un travail. Il est distillé à partir d'un vrai programme C sur lequel j'ai travaillé.

Il fait ce qu'il était censé faire, mais quelle fraction de son temps n'est pas vraiment nécessaire? Combien pourrait-il être accéléré?

Eh bien, dans la première version du programme, quelque chose d'aspect parfaitement raisonnable et non local (invisible pour un profileur) prenait 33,3% du temps. Quand il a été remplacé, ce temps a été économisé, et c'était la deuxième version du programme.

Dans la deuxième version du programme, quelque chose d'autre (invisible à tout profileur) qui pouvait être supprimé prenait 16,7% du temps. Le supprimer a conduit à la version 3.

Dans la version 3, 13% a été supprimé. De ce qui restait, 66% ont été supprimés. De ce qui restait après cela, 61% ont été supprimés!

Enfin, sur ce qui restait après, 98% ont été supprimés!

Alors, quelle est la grande image? Sur 1 000 cycles passés par le programme d'origine, combien ont été supprimés? 998!

Chaque programme est différent, mais chaque grand programme, selon mon expérience, a une série de problèmes de temps que les profileurs ne trouveront pas, que l'échantillonnage manuel le fera et que, si les programmeurs recherchent vraiment des performances maximales, peuvent être supprimés pour les grandes accélérations.