Snippet - HashtableEx - Support for IEqualityComparer and significant performance improvements

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.

1 Like

I like the class name :wink:

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 :slight_smile:

@ mhectorgato, hmm seems I am a little slow, I see your extension class was called HashtableEx. Totally unintentional I promise, I would be more than happy to rename this class if you would prefer.

Feel free to keep it, it really makes no difference to me … I was just joking around, ergo the emoticon.

Your implementation of this is much more robust - mine was just a simple hack to add functionality to the hash that was being used in an infrequent manner.

I 've just make a test in my application using Hashtable2.cs as it is in the 4.2 release of netmf, an iteration of my code takes 180ms, using your HashtableEx, the same iteration runs in 200ms.

@ leforban, the thing is that to cater to the overhead of supporting the additional level of indirection of calling to IEqualityComparer I had to significantly optimize the core Hashtable.

I think I am going to post my improved Hashtable so that you can benchmark that on 4.2 as well, this lacks the IEqualityComparer enhancements, but should be much faster than the core implementation.

@ 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.

My previous message did not appear.

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).

@ leforban

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

MyCollections.Hashtable

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

MyCollections.Hashtable

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.

1 Like