HashtableEx - Support for IEqualityComparer and significant performance improvements
HashtableEx is an enhancement to the original implementation of the Hashtable in the .NET Micro Framework.
This enhancements adds support for passing a custom IEqualityComparer to provide the hashing and comparison of the entries.
If you are still on MF 4.1 it also provides a bug fix, I have checked and the bug has been fixed in 4.2, the bug is serious in that the count is not maintained correctly when updating the associated value. This bug would also have the nasty effect of causing a performance problem because it would kick-off premature rehashes of the entire hash table contents.
You can use HashtableEx exactly like you would use the standard Hashtable. The sample shows how you could use a custom IEqualityComparer to make the Hashtable case-insensitive while maintaining O(1) characteristics of the hash table.
Note: The implementation of the custom IEqualityComparer has a direct impact on the performance of the hash table.
Thanks, actually I have a straight Hashtable as well which fixes a few bugs in the core implementation and is much faster. That version is called Hashtable, so I needed another name and Hashtable2 just didn’t sound right
@ leforban - I have just put the code up for the core Hashtable, you might want to take that for a spin and let me know what results you get with 4.2, I have not yet moved to 4.2 so I would be interested in the results.
Should I keep your namespace? I am not familiar with such modifications. In fact to include the Hashtable2.cs I copy paste the code of Hashtable.cs from 4.2 available on codeplex and modify the namespace with the name of my project (all my classes have the same namespace).
You can change the namespace to use your namespace, but I would normally suggest keeping the original namespace so that you can easily switch between implementations.
For example , you could have an aliased ‘using’ clause which points to System.Collections and then to switch to using another collection library you could point the alias to another namespace. This of course assumes that the interfaces and collection names are the same.
using MyCollections = System.Collections
Then everywhere you can use
Later when you want to try another collection you just change the alias to point to the other namespace
using MyCollections = dotnetwarrior.NetMF.Collections
And now the reference to
will use the implementation from the ‘dotnetwarrior.NetMF.Collections’ namespace.
To be honest, as a rule, I am not a huge fan of namespace aliases, but it seems that the number of conflicts in the Micro Framework classes makes them quite convenient.