Accueil Nos publications Blog Lenteur informatique : manque de puissance de calcul ?

Lenteur informatique : manque de puissance de calcul ?

Les temps de traitement incroyablement longs par rapport au travail réalisé nécessitent souvent de se poser de réelles questions sur les moyens pour y remédier. Eric WAJCMAN, développeur au sein de notre agence orléanaise nous fait part de l’une de ses expériences.


Vous connaissez surement la fameuse “loi de Moore”.

Ce n’est en rien une loi à proprement parler d’ailleurs, juste un « constat d’une époque », qui est depuis devenu un « objectif de compétitivité ». Du coup elle se vérifie globalement régulièrement.

Ce qu’elle dit, pour faire simple, c’est que tous les 2 ans, la puissance de calcul des ordinateurs double. Un programme quel qu’il soit, aura donc des performances qui s’améliorent avec le temps, si tant est que l’on mette à jour son matériel (et que ledit programme ne subisse pas des mises à jour qui alourdissent son fonctionnement bien sûr).


Et c’est bien pratique. Prenons le cas des jeux-vidéos par exemple. À quoi bon se démener à les optimiser s’il suffit d’attendre la venue de nouveaux processeurs (et que les joueurs les achètent, bien entendu…) pour que les jeux deviennent « naturellement » plus fluides ?

Nous l’avons tous entendu, y compris en entreprise :

– « Avec un nouveau processeur ça ira mieux. »

– « Tu te rends compte des milliers de traitements qu’on lui demande de faire ? »

– « C’est normal que ça soit un peu long, il y a beaucoup de règles de gestion. »

D’ailleurs, la définition et l’implémentation de ce que nous appelons communément « les règles de gestion » mériteraient au moins un article entier.

Automatiser avec son IDE

Mais remettons les choses en perspective : Qu’est-ce qu’un processeur ? 

C’est une machine composée de « minuscules transistors », et pour le coup, vraiment minuscules. C’est tellement délirant que les constructeurs doivent redoubler d’ingéniosité pour ne pas subir des effets quantiques empêchant tout calcul cohérent. Oui, nous en sommes là. Ces transistors travaillent de concert pour effectuer… des MILLIARDS d’opérations par secondes !

Certes ces opérations de calcul sont « simples » (encore que, plus ça va et plus les jeux d’instructions des CPU sont élaborés), mais tout de même, des MILLIARDS !

Alors la prochaine fois qu’un collègue vous dira :

– « Nous avons décidé de faire un batch de nuit parce que pour mettre à jour les 30 000 comptes, il faut 2h de calcul avec nos serveurs actuels. »

Posez-vous la question : « Vraiment ? ».

Le problème vient-il vraiment du Hardware, ou bien du Software ?

S’il faut 2 ans pour doubler les performances en attendant le prochain CPU, pourquoi ne pas profiter d’une partie de ce temps pour voir si côté logiciel il ne serait pas possible de faire pareil ? Voire mieux. Beaucoup mieux même.


La véritable source du problème vient quasi systématiquement d’un manquement au niveau de la conception technique, donc en amont, avant le développement. Pour autant, arriver en cours de projet ne signifie pas nécessairement que tout espoir est perdu.

Des exemples, j’en ai connu, dans toutes mes missions, chez tous les clients, quel que soit le domaine : finance, télécom, gestion, y compris dans les systèmes embarqués. En voici l’un des plus frappants :

Un jour j’ai récupéré un applicatif de type « batch de nuit » justement, codé en python, qui avait été initié par des étudiants. 

Ces derniers n’avaient pas eu le temps de le finir fonctionnellement (leurs délais étaient serrés, et le besoin métier n’était pas évident de prime abord.)

Le but du batch en question était d’agréger des données entre elles, en partant d’un élément central servant de clef, pour en retrouver des informations associées provenant de différentes sources, puis de stocker le tout dans une base de données.

En bref : quelques cas fonctionnels saugrenus, une complexité pas trop élevée, loin de là (la complexité fonctionnelle, et non « algorithmique », qui elle était justement problématique. On y vient.)

Il y avait environ 1/2 million de lignes à traiter chaque jour, par ce batch.

La première fois que j’ai testé ce traitement sur un jeu de données complet, il a fallu l’arrêter au bout de 2 heures tellement c’était long, pour constater qu’il était loin d’avoir fini. D’après une rapide estimation, il en aurait eu pour au minimum 14 jours pour tout finir (et pour rappel, le traitement était encore incomplet par rapport à la demande métier).

Sans rentrer dans les détails techniques, ce code accumulait un mélange de :

  • Appels de la base de données pour chaque champs de chaque ligne à modifier, au lieu d’agréger le tout »
  • Ré-instanciation d’objets à chaque tour de boucle »
  • Boucles imbriquées à répétition, sans aucune réutilisation des informations déjà trouvées lors des passages précédents »
  • et de manière générale : un manque cruel d’utilisation de caches


Bref, niveau optimisation, on pouvait mieux faire. Et c’est peu dire, car il aura fallu moins d’un mois, pour refaire l’intégralité du traitement, et finaliser complètement le fonctionnel manquant.

Résultat : le traitement total ne prenait plus que 27 secondes… Soit un facteur d’optimisation de plus de 40 000 !

Et encore, il s’agissait là de refaire quasi intégralement le développement en question, donc effectivement c’est un peu « long » à réaliser. Mais la question est de savoir : est-ce que ça en vaut la peine ? (ici c’est obvious, capitaine, mais en fait, il faut se la poser dans tous les cas).

L’optimisation : un gain conséquent pour vos projets

Parce que, oui une « refonte » ça fait souvent peur aux demandeurs, à juste titre d’ailleurs. Mais vu les gains potentiels, ça se défend vraiment, car bien souvent les optimisations ne demandent que quelques heures ou jours, le temps de trouver ce qui ne va pas et de le modifier. 

Et les modifications les plus petites sont souvent les plus impactantes, comme par exemple l’ajout d’un index ou deux en base de données, qui peuvent facilement multiplier par 10, 100, voire 1000, les performances d’un traitement.

Avec les années, plus on a d’expérience et plus on se rend compte facilement de l’anormalité de certains temps de traitement par rapport aux actions à faire par ledit traitement. Mais commençons le plus tôt possible tant qu’à faire. Surtout que les gains sont nombreux : 

  • meilleure compétitivité du projet
  • baisse de couts énergétique
  • voire même baisse de l’impact écologique potentiellement

En résumé

Que vous soyez développeur, MOE, ou chef de projet, accordez-vous de temps en temps le droit de vous demander :

« Est-ce que ce temps de traitement est légitime ?

Ne pourrait-on pas allouer un jour ou deux d’analyse pour voir s’il n’y aurait pas une optimisation qui en vaille la chandelle ? »

Oui, parfois rien n’est trouvé, parfois même il n’y avait rien à améliorer. Mais d’expérience de lead technique, il y a bien plus souvent des optimisations réalisables que l’inverse. Et des conséquentes !

Eric, développeur au sein de l’agence d’Orléans.