Les tables de hachage sont très bien lorsqu'il y a beaucoup de choses à stocker.
Les requêtes HTTP qui comportent plus de 100 valeurs sont rares.
Pour chaque requête il faut se palucher la construction d'une table de hachage. Et pour chaque accès aux valeurs il faut se farcir la recherche dans la table en question (hachage du nom recherché, puis recherche). Ces opérations sont bien plus coûteuses que si s'était "rangé en vrac", à condition de ne pas avoir trop de valeurs. Ce qui est le cas dans 99.9% des cas (valeur issue de mes notes personnelles, là, dans le tiroir).
Tout ça pour ?
Tout ça pour perdre du temps dans 99.9% des cas. Pour les 0.01% restant, le programmeur, sachant qu'il n'y a pas de table de hachage, les fourre dans une qu'il construit pour l'occasion et le tour est joué. Comme on fait d'habitude quoi.
Et ô surprise, ne pas complexifier aurait encore évité des bugs. Dingue.
# N'optimiser que si nécessaire
Posté par Kerro . En réponse à la dépêche Le colonel Moutarde, sur la table (de hachage), avec un livre de maths. Évalué à -5.
Les tables de hachage sont très bien lorsqu'il y a beaucoup de choses à stocker.
Les requêtes HTTP qui comportent plus de 100 valeurs sont rares.
Pour chaque requête il faut se palucher la construction d'une table de hachage. Et pour chaque accès aux valeurs il faut se farcir la recherche dans la table en question (hachage du nom recherché, puis recherche). Ces opérations sont bien plus coûteuses que si s'était "rangé en vrac", à condition de ne pas avoir trop de valeurs. Ce qui est le cas dans 99.9% des cas (valeur issue de mes notes personnelles, là, dans le tiroir).
Tout ça pour ?
Tout ça pour perdre du temps dans 99.9% des cas. Pour les 0.01% restant, le programmeur, sachant qu'il n'y a pas de table de hachage, les fourre dans une qu'il construit pour l'occasion et le tour est joué. Comme on fait d'habitude quoi.
Et ô surprise, ne pas complexifier aurait encore évité des bugs. Dingue.