Uniqid ou la contre-intuitivité des arguments
D'après le manuel PHP, le prototype de la fonction uniqid est le suivant :
string uniqid ( [string prefix [, bool more_entropy]] )Le deuxième paramètre à l'air réellement intéressant, dans la mesure où il assure une meilleure unicité de la chaine produite. Une propriété qui de toute évidence nous intéresse si on utilise cette fonction uniqid.
Sans s'étendre sur la probabilité de collision entre les 2 appels (ce que j'étendrai plus longuement dans un autre article), je voulais juste montrer la différence de vitesse d'exécution qu'induisait ce paramètre more_entropy. Un petit script faisant 100 appels à uniqid avec une valeur possible du paramètre, nous donne le résultat suivant (!) :
Chose extrêmement intéressante, le temps d'exécution de la fonction est 3 ordres de grandeurs en dessous si on demande une meilleures unicité du résultat.100 * uniquid(mt_rand()) en 0.799283981323 seconde
100 * uniquid(mt_rand(), true) en 0.00346183776855 seconde
La question obligée est donc : pourquoi est-ce que cette fonctionne ne prend pas par défaut cette option, puisqu'elle a tous les avantages (meilleures résultats, plus rapide) ?
1 commentaire:
Peut-être pour des raisons de compatibilité, ou parce que la version "more entropy" est un peu (ou beaucoup?) un hack:
http://www.google.com/codesearch?hl=en&q=+uniqid.c+show:FtNkOWqaM2w:tGfA8CeGHn8:XzhLYs_3iiw&sa=N&cd=20&ct=rc&cs_p=http://www.angstrom-distribution.org/unstable/sources/php-5.1.4.tar.bz2&cs_f=php-5.1.4/ext/standard/uniqid.c#a0
Dans le cas de "more entropy", la fonction va juste ajouter un nombre pseudo-aléatoire à la suite du uniqid, qui est juste défini par la date/heure au moment de l'appel. Peut-être que la bidouille pseudo-aléatoire supplémentaire est pas considérée suffisamment propre.
Par contre l'autre surprise, c'est que sans "more entropy", la fonction fait un usleep(1), pour assurer l'unicité en cas de deux appels dans la même microseconde.. c'est assez immonde comme solution :-)
Enregistrer un commentaire