C’est cool de la part de Rockstar !
J’imagine que Nintendo, Sony ou d’autres studios un peu cons l’aurait attaqué en justice pour avoir décompilé leur binaires…
~
Sinon, d’un point de vu technique, ça semble être le problème similaire à ça :
for (var i = 0 ; i < tableau.length() ; i++) {
// code ici
}
Pour les non-programmeurs : la boucle for permet d’itérer sur un tableau (qui est un ensemble de N variables à la suite). Chaque variable du tableau est repéré par son indice i.
Avec for, on commence par mettre i à 0 (pour la zéroième case, donc la première en fait). Ensuite, on vérifie que i est plus petit que la taille du tableau : si le tableau fait 10 cases, on doit pas chercher la case n°11 ou 12, mais s’arrêter à 10. Enfin, à chaque tour de la boucle for, on incrémente i : au second tour, on regarde la case 2, puis la case 3, et ainsi de suite.
Le problème ici ? c’est qu’à chaque tour de boucle, il effectue le calcul « i < tableau.length() », c’est à dire qu’il regarde le tableau, calcule la longueur, et voit si l’itérateur i est bien en dessous.
Si vous ne programmez pas, vous ne pouvez pas voir le problème, mais en vrai, calculer la longueur d’un tableau prend du temps. Et ici, ce calcul est fait à chaque bouclage.
La solution ? Calculer la longueur du tableau une fois, et mettre le résultat dans une variable :
var longueur = tableau.length();
for (var i = 0 ; i < longueur ; i++) {
// code ici
}
Ou mieux, en JS comme en PHP, on peut faire ça, pour garder ça sur une ligne :
for (var i = 0, longueur = tableau.length() ; i < longueur ; i++) {
// code ici
}
Notons qu’ici, on rajoute quelques octets de code, on rajoute une variable intermédiaire, mais on gagne énormément en vitesse : la longueur du tableau est calculée une seule fois au début.
En vrai, ceci est une de ces petites astuces à la con qui peut TOUT changer dans un code, et elle est applicable à tous les langages de programmation (à noter qu’on aurait pu utiliser également la boucle while).
Bref, ce genre de détails de code m’a déjà permis de gagner énormément de temps dans mes scripts.
~
Un autre exemple ? En JS, en manipulant le DOM : ajouter un élément HTML dans le DOM prend du temps : il y a l’ajout lui-même, le reflow (calcul de sa position sur l’écran et décallage des éléments déjà à l’écran), le repaint (son affichage effectif sur l’écran), etc.
Si l’on a une boucle for() qui ajoute itérativement plusieurs éléments, ne les ajoutez pas à chaque bouclage !
Faites plutôt un HTMLFragment, auquel vous ajoutez les éléments. Une fois la boucle for() terminée, vous ajoutez le HTMLFragment à la page. Au lieu d’avoir un calcul du reflow/repaint de la page pour chaque élément, on ne l’a qu’une seule fois.
Et ne vous dîtes pas « mais de toute façon je n’ajoute que 5 éléments ». Non : un jour vous vererz, votre boucle sera plus grande, de 1000 à 10000 éléments par exemple. Et là cela prendre un temps de malade et vous ne saurez pas d’où ça vient.
L’optimisation commence très bas et très tôt dans le code source.
~
Dernier exemple : mon blog utilisait autrefois un moteur de blog où chaque article, chaque commentaire était un fichier texte, dans un dossier correspondant au mois en cours. Un peu comme PluXML.
C’était assez lent, mais j’ai réussis à améliorer d’un coup la vitesse. Comment ? En partant du simple constat qu’un commentaire ne pouvait toujours qu’être posté après l’article qu’il commente.
Il était donc inutile de parser les commentaires de janvier-2010 pour un article datant de février-2010. Et vu que la page principale du blog n’affichait toujours que les derniers articles, cette page s’affichait toujours très vite.
Bon, depuis j’ai basculé mon blog sur du SQLite, bien plus rapide et plus adapté : on peut trier immédiatement les commentaires associés à un article. Les bases de données sont optimisés pour ce genre de tri, ce qui n’est pas le cas de PHP.