Bloc-notes de Darathor

Préambule…

Hier, j’avais à parcourir un tableau d’objets (pouvant avoir potentiellement des centaines voire exceptionnellement milliers d’entrée) pour rechercher si l’identifiant de l’un d’eux se trouvait dans un second tableau. J’avais commencé par utiliser pour ça la fonction in_array() à chaque itération pour voir si l’identifiant de l’objet était présent ou non dans le second tableau.

En voyant cela, un collègue m’a fait remarquer que ce serait peut-être plus performant de construire un tableau dont les clés sont les valeurs du second tableau (via array_flip()) pour pouvoir utiliser isset() au lieu de in_array() et voici les résultats obtenus :

Structure du bench

Le bench consiste à rechercher 100 000 fois la même valeur dans le tableau array('11345', '7437', '7329', '45494', '7894311', 'sdfsdg', 'qsqsdcirt', 'd787 sdfs df'), avec trois méthodes différentes :

• in_array()
• array_flip() suivi de isset()
• array_flip() suivi de array_key_exists()

Le test est effectué avec deux valeurs différentes : d’abord avec la première valeur du tableau (cas théoriquement le plus favorable puisqu’on arrête la recherche une fois la valeur trouvée) puis avec une valeur qui n’est pas dans le tableau (cas théoriquement le plus défavorable puisqu’on est obligé de parcourir tout le tableau). Le résultat en conditions réelles sera donc compris dans cette fourchette.

Cas in_array()

Code exécuté :

Cas favorable ($value = '11345') : ~0.33 secondes
Cas défavorable ($value = 'uottuyi') : ~0.52 secondes

Cas isset()

Code exécuté :

Cas favorable ($value = '11345') : ~0.12 secondes
Cas défavorable ($value = 'uottuyi') : ~0.09 secondes

Cas array_key_exists()

Code exécuté :

Cas favorable ($value = '11345') : ~0.27secondes
Cas défavorable ($value = 'uottuyi') : ~0.24 secondes

Et pour de plus petites quantités ?

Les grands volumes c’est bien mais qu’est-ce que ça donne quand on a peu d’itérations ?

Un test à 5 itérations au lieu de 100 000 donne environ le même résultat pour les trois méthodes : avec ~6E-05 secondes pour les méthodes 1 et 3 et ~5E-05 pour la méthode 2.

Tandis qu’un test sur une unique itération donne la première méthode gagnante avec ~4E-05 secondes contre ~5E-05 pour les deux autres (à ce niveau c’est le array_flip pour transformer les valeurs en clés qui coute cher).

Conclusion

À moins d’avoir toujours très peu d’itérations (moins de 5), la méthode passant par array_flip() puis isset() est d’assez loin la meilleure (environ quatre fois plus rapide sur des grands nombres et pas plus lente sur des petits).

En passant, on remarque aussi qu’avec cette méthode, rechercher une valeur qui n’existe pas dans le tableau est plus rapide que de rechercher la première valeur du tableau, même si je ne vois pas forcément trop pourquoi

Ça y est, Tab Mix Plus est enfin compatible Firefox 3 ! C’était la dernière extension que j’attendais pour pouvoir mettre à jour, c’est donc chose faite

C’est l’occasion de relever un point noir sur le moteur de recherche d’extensions sur le site de Mozilla :

1. en recherchant “tabmixplus” ou “tabmix”, j’obtiens 5 résultats mais pas Tab mix plus (les 5 résultants faisant référence à l’extension dans leur description en tant que “TabMixPlus”).
2. en recherchant “tabmix plus”, je n’obtiens aucun résultat.
3. en recherchant “tab mix plus”, je n’obtiens aucun résultat non plus est là c’est nettement moins compréhensible !
4. ce n’est qu’en recherchant “tab mix” que j’obtiens enfin le résultat recherché.

En soi, ça peut se comprendre avec un algorithme simple de recherche (à part pour le point 3). J’ai d’ailleurs testé sur quelques sites pour voir et je n’en ai trouvé que parmi les moteurs de recherches (Google et Live Search) qui me trouvent les résultats en collant les mots.

C’est un point sur lequel les différentes implémentations de moteurs de recherches internes des CMS, forums, etc. devraient se pencher, parce que quand on cherche une marque ou un nom, on n’a pas forcément le découpage précis en tête…

Les habitués du mode console n’apprendront probablement rien de cet article mais pour ceux qui, comme moi, ne s’en servent qu’occasionnellement, ça peut s’avérer instructif.

Recherche dans l’historique

On a vu il y a quelques temps qu’on pouvait alléger l’historique des commandes saisies en ignorant les doublons. Si la commande que vous recherchez est malgré cela noyée dans la masse, vous pouvez utiliser ctrl+r et taper les premiers caractères de la commande recherchée pour la retrouver.

Blocage de la console

Le raccourci ctrl+s permet de suspendre le terminal (saisie et exécution). Pour le débloquer, le raccourci est ctrl+q donc si le terminal se bloquer mystérieusement (ce qui peut arriver vu que ctrl+s est le raccourci de sauvegarde dans la majorité des éditeurs de texte graphiques et qu’il n’est pas rare de le taper machinalement après une saisie), tentez ça avant de frapper sauvagement sur votre clavier

Retrouver les plus gros fichier de votre système

Une partition est pleine, il faut faire de la place ! Oui, mais où sont les gros fichiers qui consomment tout l’espace ? Telle est la situation dans laquelle je me suis retrouvé pas plus tard qu’il y a 5 minutes…

Après une brève recherche sur le net ( que je en compte pas refaire à l’avenir, d’où l’intérêt d’en donner le résultat ici ), voici la réponse avec une combinaison de du et sort :

Soit dans mon cas, pour lister tous les dossiers du système :

On retrouvera alors les dossiers contenant les plus gros fichiers en fin de liste. Par contre ça peut mettre un peu de temps à s’exécuter vu que ça fait le tour de tous les dossiers.