Dinoblog

L’optimisation PHP par certains développeurs n’est pas justifié. En effet, l’approche qu’on certaines personnes sur l’optimisation et langage qu’ils utilisent n’est pas réellement approprié. J’ai été un peu choquer par la présence d’article complet et bien fait sur l’optimisation de vos scripts PHP mais que sur le plan du langage. C’est à dire que tout au long de cette article, on apprends surtout l’utilisation de notions obscur du langage PHP qui enlèverait 1 ou 2 nano-seconde pour l’exécution de votre script. Est ce là vraiment l’optimisation ? Surtout quand on observe une requête SQL dans une boucle … Ceci traire de l’ordre des micro-optimisations. Mais pour autant, faut il s’attarder à ce genre de détail pour la publication de nos scripts PHP ? Doit on passer un temps certain à remplace echo "Mon texte: $number"; par echo 'Mon texte: $number';. Ceci est il vraiment justifié ? L’optimisation de vos scripts PHP ne doit pas passer par là. Du moins, cela ne doit pas être priorité (car au final, on s’en contre fiche et cela dénote plus de la mauvaise qualité du langage que l’acquisition de quelques nano-secondes). Cette article va donc vous expliquer là il faut optimiser votre code.

La première optimisation que l’on doit faire, c’est au niveau algorithmique. Par exemple, il est parfois plus judicieux d’utiliser le tri par insertion ou par sélection que le tri rapide pour une liste courte. Il s’agit non seulement de savoir le complexité de l’algorithme que l’on utilise, mais aussi de connaître ou de rechercher d’autres algorithmes qui peuvent être plus rapide suivant le cas. Souvent, certains utiliseront un algorithme très rapide dans certains cas ce qui peut ne pas être adapter à leurs situations et dégrader la vitesse de leurs programmes. Mais cela ne concerne pas seulement vos algorithmes mais aussi dans vos instructions (comme en Python avec list.append() et list.insert()) où il faut ce renseigner sur leurs complexités (et leurs utilisations) et faire les opérations nécessaires pour savoir la complexité final de votre algorithme si elle intéressante ou pas. Après, il faut épuisé toutes les possibilités qui vous sont offertes. Rien ne doit vous échapper et vous devez être sûr qu’il n’existe aucuns autres moyens plus rapide pour résoudre votre problème. Il ne s’agit donc pas ici de simplement appliquer ce que nous X ou Y en disant que c’est plus rapide que de faire ceci, il s’agit de faire une réflexion non seulement dans ce qu’on utilise mais aussi dans ce qu’on devrait utilisé.

L’optimisation, notamment dans des langages qu’on compile, ce n’est pas aller au plus bas niveau. J’entends encore dire qu’un programme en Assembleur est plus rapide en C. C’est une erreur car aujourd’hui, les compilateurs créer un programme autant rapide qu’un autre programme écrit en assembleur (tant que le programmeur sait très bien programmer en assembleur). De plus, cela allonge votre temps de productivité (car il est plus long de faire un programme en assembleur qu’en C) et vous pénalise plus qu’autre chose. Le gain de rapidité n’y est pas dans ce genre de méthode. Néanmoins, il convient parfois d’utiliser localement un langage bas niveau pour des problèmes d’architectures (comme par exemple un logiciel qui travaillerait sur plusieurs machines en parallèles ou dans les systèmes embarqués). Mais ce genre de cas est plus exceptionnel, l’utilisation d’une telle technique ce restreint donc à certains cas limites.

Il s’agit ensuite de porter une véritable réflexion dans la structure de votre programme. Écrire du code astucieux qui vous fait gagner une nano-seconde n’est rien en comparaison d’un code très bien structuré, lisible et aisé à maintenir (c’est d’ailleurs là où on repère la qualité d’un programmeur). Le véritable problème, c’est que cette réflexion ce porte dès le départ du projet et certains programmeurs la sautent immédiatement ce qui ce termine par établir une nouvelle structure et tout recommencer (et là, c’est une véritable perte de temps). Il faut donc définir des structures de données et connaître des algorithmes qu’on appliquera après qu’on est justifié si ils nous sont appropriés.

Après, pour ce qui est de C++, on peut faire confiance à notre compilateur qui peut faire des optimisations dont, nous, nous ne penserions pas dès la première approche. Notamment en utilisant des mots clés comme const. Mais il faut le spécifier explicitement à votre compilateur dans votre code. Mais ça, c’est de l’ordre de votre langage dont vous devez en connaître tout les secrets (et il ne s’agit pas de connaître les endroits obscurs du dit-langage mais de voir tout ce qu’on peut en tirer en connaissance des mot clés).

Ce que je veux faire comprendre ici, c’est que l’optimisation du type echo cité au début de cette article ne sert à rien si vous ne procéder pas aux optimisations citées ci-dessus. Ensuite, un autre point mais qui est de l’ordre de la productivité (mais aussi de l’organisation), c’est d’optimiser après que vous ayez fait quelque chose de fonctionnel. L’optimisation pendant la création est plus un frein (car vous reviendrez sur votre code, vous recommencerez, vous repartirez pour ensuite revenir sur votre code, etc …) qu’un gain. Alors faîtes quelque chose qui fonctionne avant de vous posez la question si votre script et rapide ou non.