Dans certains domaines, on a pas d'autre choix que l'obsession de la performance. C'est vrai dans le développement embarqué: certains équipements doivent être autonomes sur une pile pendant des années et on fait la chasse aux milliampères, on doit faire des arbitrages au niveau du code aussi.
C'est aussi une préoccupation à grande échelle: un data center fait naturellement la chasse au gaspillage d'électricité.
J'ai souvent vu du code avec des boucles while, "idle" la plupart du temps, mais qui sont mal fichues et font tourner le CPU à 100%, ce sont des fautes de programmation qui peuvent être facilement évitées. Dans certains cas, un timer est plus adapté.
Petite anecdote qui remonte à une vingtaine d'années: un client avait un serveur sur lequel tournait un ensemble de tâches SQL, avec des transferts de fichiers entre pays par modem etc. Du jour au lendemain, ce processus relativement lourd qui prenait 4 heures est passé à 8 heures. Il faut savoir que ce processus se déroulait pendant la nuit, et que tous les fichiers devaient être prêts quand les employés commencent leur journée le matin.
La cause du problème: quelqu'un a installé un screen saver sur ce serveur, c'était manifestement un programme mal codé qui bouffait les ressources en CPU et plombait le serveur...
Performance çà va de pair avec
stabilité aussi. quand un programme "mission-critical" tourne en continu dans un environnement de prod avec des
fuites mémoires, à un moment vous allez avoir un retour du client car les bugs et l'instabilité du code vont commencent à se voir
Je suis d'accord avec Walfrat, les développeurs sont fainéants (moi aussi), et il faut bien le dire on n'a pas toujours le temps de faire de la qualité ou aussi bien qu'on voudrait. Personne ne se soucie des performances tant que ça ne pas pose un problème voyant. Et il faut bien reconnaître que cela ne va pas de soi: il faut apprendre certaines bonnes pratiques de coding, mais il faut aussi apprendre à mesurer et tracer le code.
Mais ça ne fait pas partie des exigences des employeurs non plus, sauf exception. A partir de là il ne faut pas s'étonner que le sujet soit relativement délaissé.
Je pense quand même qu'avec l'automatisation la qualité peut s'améliorer. Par exemple, il est de plus en plus courant qu'un outil tel que Valgrind soit intégré à la chaîne CI/CD.
7 |
0 |
La performance est un facteur crucial dans le cycle de vie d'un logiciel et ce besoin gagne en importance dès la phase de conception du produit. Toutefois, certains segments de la communauté des développeurs estiment que les préoccupations en matière de performances sont dépassées et ne s'inscrivent plus dans les priorités de l'industrie. Pour Casey Muratori, Lead programmeur chez Molly Rocket Inc, ces genres d'excuses visant à reléguer la performance au second plan ne sont tout simplement pas valables, et il est facile de le démontrer en observant les efforts menés par les grandes firmes technologiques, à l'instar de Facebook ou de Twitter, au cours de ces dernières années....
Envoyé par denisys
