Hashtable - Improved performance
This hash table implementation adds no new features to the core implementation, but contains significant performance improvements over the core version, at least for framework 4.1.
In addition to the performance improvements there is a bug fix for the Count property which was not maintained correctly in the 4.1 implementation, but I having checked the code I can confirm that the bug is fixed in 4.2.
This was my starting point for the HashtableEx which adds support for IEqualityComparer, if all you require is the pure performance enhancements then this class is the better option.
Framework 4.1 Bench marks
Inserting 1000 keys
System.Collection.Hashtable - 6012 ms
dotnetwarrior.NetMF.Collections.Hashtable - 4519 ms
Contains look-up 1000 keys
System.Collection.Hashtable - 1956 ms
dotnetwarrior.NetMF.Collections.Hashtable - 1633 ms
1 Like
So your version seems really better in terms of runtime to insert element, but what about retrieving the value, even if you claim an O(1), my bench seems to prove that it is a litlle bit slower but may be I am wrong and this difference in terms of runtime come from a side effect…
@ leforban, O(1) is not a claim by me, but a performance characteristic of the hashtable algorithm, assuming of course it is implemented correctly. Just to be clear, all implementations for Java, .NET desktop and the NETMF version are on average O(1), when the internal array is required to grow to accommodate more data the regrow is in fact an O(n) operation that is why if you know the number of items you intend to insert into the hash table it is always good to preset the capacity to avoid the costly growths.
Anyway, back to your point, could you share your benchmark code so that I could compare that on 4.1.
Unfortunately, I can’t share this code but may be if I have time I can try to isolate where the overhead comes from. May be it is somewhere else, but I do not think so, since I just rename all HashTable2 into HashTableEx and exclude HashTable2 from the project.
@ Leforban, but HastableEx is the hashtable with the IEqualityComparer. If all you need is a drop in replacement for the core Hashtable then you should use the new code that I posted which is called Hashtable, but in my dotnetwarrior namespace.
This may be the reason. I renamed your namespace with the namespace of my project. Something is not clear to me. What should I do with namespaces? I have a namespace in my project (namespace USU). I do not know how to use a class defined in an other namespace…
@ leforban - If you rename the namespace, that is fine, do you also rename the actual class, because I see you are referencing HashTable2.
Ok I took the last version of your code (HashTable) and rename the namespace into USU. I run the code and it runs in 160ms versus 180ms for HashTable2 based on the 4.2 version available on codeplex. I don’t know why I see 200ms at the beginning, may be because of bad namespace or something like that. Anyway, in my case 20ms of improvement is a huge gain (10%).
Whew, I was worried for a moment 
it would not make sense that it would perform slower. Thanks for testing.
it would not make sense that it would perform slower. Thanks for testing.