Closed TheoWinterhalter closed 9 years ago
dbaelde
commented
9 years ago C'est bien de relire le code des autres, et la remarque est bonne. Il manque juste, peut être, une interpellation explicite des auteurs de Hashtbl.create sur des valeurs nulles ou non premières: @Mazzocchi @VLanvin @MetaMetaMath (je vous laisse chercher les Hashtbl.create en question: grep est votre ami --- et git blame est le mien)
Mazzocchi
commented
9 years ago Mon serveur de reconnexion a un Hashtbl.create 0 mais il n'appartient en rien au projet pour le moment !
TheoWinterhalter
commented
9 years ago C'était pas pour être méchant @Mazzocchi. ;) C'est pas forcément évident, c'est pour ça que je l'ai souligné. Je ne disais pas non plus que tu pourrissais les performances ou quoi, hein ?
Mazzocchi
commented
9 years ago Non non, t'inquiète pas ! Et effectivement je ne savait pas que les tables de hachage été géré de cette manière. Mais j'ai l'impression qu'il y a peu de chance que ce bout de code vois le jour dans le projet.
Salut,
J'ai vu ceci et j'ai pensé qu'il y avait sans doute un problème concernant la taille initiale de la table de hachage — ce n'est pas le seul endroit, j'ai aussi vu passer des 10 et 50 comme tailles de base.
Si je ne me trompe pas, la table est gérée de telle sorte que dès que les entrées dépassent la moitée de la taille, la taille est doublée. Commencer à 0 est donc très inefficace puisque beaucoup de copies risquent d'être effectuées. De plus, il me semble qu'il est préférable de choisir une taille correspondant à un nombre premier, ceci permettant d'éviter des collisions (enfin de diminuer leur nombre).
Ce n'est sans doute qu'un détail, mais j'ai déjà senti personnellement un impact sur les performances après avoir mal choisi la taille de départ. Il ne faut pas hésiter à être large (bien sûr, on n'est pas obligé de prendre 131071) si ça peut faire économiser du temps de calcul à recopier les données.
N'hésitez pas à me reprendre si je fais fausse route !