|
From: Julian S. <js...@ac...> - 2007-07-11 23:57:11
|
> Christoph, this is very helpful stuff -- pathological cases like this are a Yes, I agree. Excellent work. I looked at the revised m_hashtable.c and it looks plausible, although I'm not familiar with its implementation, and no diff. > The implementation has at least the following flaws: > > - The primes are from > http://planetmath.org/encyclopedia/GoodHashTablePrimes.html and stop at > 31 bits. Sounds fairly harmless. AIUI from reading the resize function, if you use up all the prime numbers then after that you double the size of the table and add 1. Yes? > - One has to call VG_(HT_destruct)(VgHashTable table) because there are > two allocations for each table. Not sure what the significance of that is. Does it change the behaviour or required behavior for users of the hashtable? > - There is an additional indirection for the chains array. One could get rid > of it but would have to change the HT_add_node interface. Sounds harmless, apart from minor performance loss, yes? If the hash table automagically expands to suitable sizes, then maybe we can get rid of the argument to VG_(HT_construct) and start off at primes[0] ? I'll look at the Superblock fix too. J |