Expérience : le coût caché des temps de build lents
(github.blog)- Démonstration par l’expérience de « pourquoi des temps de build rapides sont importants pour une entreprise » et de « les ressources cloud puissantes sont-elles vraiment coûteuses ? »
- Test des temps de build sur GitHub Large Runner de 2 à 64 cœurs (noyau Linux Fedora)
Le coût des temps de build lents pour une entreprise
- En prenant un salaire annuel moyen de développeur à $150K, cela représente $75 de l’heure
- Si un build prend 1 heure et que le développeur ne fait rien d’autre, l’entreprise paie simplement $75 de coût
- Résultats de l’exécution (Fedora 36)
- Cœurs (prix par minute) - temps total de build - coût par build - coût développeur (1 personne)
- 2 cœurs ($0.008/min) - 310 min - $2.48 - $389.98
- 8 cœurs ($0.0032/min) - 92 min - $2.94 - $117.94
- 16 cœurs ($0.064/min) - 55 min - $3.52 - $72.27
- 32 cœurs ($0.128/min) - 35 min - $4.48 - $48.23
- 64 cœurs ($0.256/min) - 27 min - $6.91 - $40.66
- Conclusion : plus il y a de développeurs impliqués, plus il est efficace de dépenser pour du matériel plus puissant
Le coût du changement de contexte pour une entreprise
- Si l’on suppose que le développeur effectue d’autres tâches pendant l’exécution du build
- Le changement de contexte a lui aussi un coût. Selon des recherches, il faut en moyenne environ 23 minutes
- Personnellement, j’ai l’impression qu’il faut plutôt une heure pour passer d’un travail sur lequel on était concentré à un autre
- Résultats de l’exécution (calculés sur environ 30 à 15 minutes)
- Cœurs - temps de build - coût par build - coût développeur partiel (1 personne, 30 min) - coût développeur partiel (1 personne, 15 min)
- 2 cœurs - 310 - $2.48 - $39.98 - $21.23
- 16 cœurs - 55 - $3.52 - $41.02 - $22.23
- 64 cœurs - 27 - $6.91 - $44.41 - $25.66
- Avec l’hypothèse d’un coût développeur de $75 de l’heure, il est bien plus efficace de dépenser davantage pour la machine
- Même l’option la plus chère à 64 cœurs ne représente qu’un cinquième du coût horaire d’un seul développeur
Conclusion
- Payer pour un meilleur matériel revient en réalité moins cher et c’est aussi mieux pour les développeurs (moins de distractions)
- Dans cette expérience, payer $4 à $5 de plus pour le temps de build permet d’économiser $40 pour un développeur seul, et plus de $200 pour une équipe de 5 personnes, tout en évitant une heure perdue en changement de tâche
- Bien sûr, dans une grande entreprise, dépenser $4 à $5 par build peut finir par représenter une somme importante, mais le coût de productivité perdu augmente lui aussi
- Dépenser plus pour de meilleures performances CPU est récompensé avec le temps.
Bien sûr, les développeurs vous en remercieront
9 commentaires
Je valide.
https://xkcd.com/303/
On dirait que se retrouver sans rien d'utile à faire pendant le temps de build est un phénomène universel.
Waouh, c’est vraiment un sujet qui m’intriguait. Le blog GitHub a aussi plus de choses intéressantes à voir que je ne le pensais. Ça me rassure de voir que je ne suis pas le seul à faire autre chose pendant les builds ou à rester constamment focalisé dessus (?).
J’avoue. Je préfère les desktops aux portables Plus.
Je comprends tout à fait. Je suis chercheur en deep learning, donc j’utilise plusieurs machines en même temps.
Comme je lance souvent des expériences, il m’arrive souvent d’utiliser toutes les ressources, et dans ces moments-là, il y a des temps morts qui se créent par intermittence.
Et pendant les expériences, se consacrer à d’autres tâches demande aussi mine de rien de l’attention.
Le salaire annuel moyen est de 150 k$ ?
Il m’est arrivé de trouver frustrantes les limites de performances d’un PC ou d’un serveur, et j’ai clairement eu l’impression d’être moins productif que lorsque tout fonctionne rapidement et de manière fluide.
Mais c’est vrai, au fond.
Autrefois, j’ai travaillé sur un projet où chaque build prenait une heure...
Quand on lance un build, on finit toujours par faire autre chose en attendant que ça se termine lol
Et pendant le build, le PC se met parfois à ramer aussi...
Même quand on est occupé par autre chose, on finit par vérifier de temps en temps l’avancement du build, donc c’est difficile de bien se concentrer.
C’est certes un article promotionnel pour GitHub Large Runner, qui dit en gros d’utiliser de bonnes instances de build…
Mais le point n°9 du The Joel Test — « achetez à vos développeurs le matériel le plus cher que vous pouvez vous permettre » — s’applique tout autant à l’ère du cloud.