Main Site Documentation

HashTable that grows up


#1

Just a dummy summary that illustrate a problem in my larger application:

using System;
using Microsoft.SPOT;
using System.Collections;

using GHIElectronics.NETMF.Hardware;

namespace EMX_Application1
{
    public class Program
    {
        public static void Main()
        {
            Hashtable HT = new Hashtable();
            HT[0] = (int)1000;
            for(int i = 0;i < 100000;i++)
            {
                HT[0] = i;
                Debug.Print("HT" + HT.Count);
            }

        }

    }
}

As you will notice the Hash Table grows up while I did not add new entry to the HT. This seems that updating a value of HT item can not be done as I did. Would you have any advice?

Regards


#2

you are always using a key of zero. who do you expect the count to get grater than one?


#3

@ Mike
That is the essence of the issue he is experiencing. He is just updating the same item in the HT, but HT grows in size.

I haven’t tried it, but sounds like a bug.


#4

Just verified it in emulator. It grows indeed, sometimes it shrinks back a bit, but then it grows again.
I have also tried it in regular framework. Big brother works fine!

It is a bug in MF implementation. Please report it on MF site.


#5

What happens if you enumerate the contents of the HT?


#6

There’s only one element in the HT, the rest of the HT point to null but the larger the HT is the slower is my application…

As an example I put 14 items in a HT at the beginning of my applications, 1 iteration of my code takes about 250ms to execute. After two minutes of execution, the HT count is about 5000 (without adding new element) and my applications run in 1seconde per iteration.

Could it be a bug or a misuse HT? I mean updating an item should be HT[key]=value; right?


#7

I can’t find the Hashtable in the NETMF code. Anyone have a pointer to it?


#8

This should be in System.Collections


#9

I found it here:
http://netmf.codeplex.com/SourceControl/changeset/view/9366#69502

Actually this seems to be solved in changeset 9366. For those who are aware with release of .netmf.

How can I know in which version of .netmf this bug is solved? (I am using the 4.1.7 )

Should I update in 4.1.8 or try a 4.2 (still in beta? no?)


#10

If you’re using Cerberus or Cerb40, you’re using 4.2, otherwise, you’d need to wait for GHI to release an updated firmware.


#11

damn, this is a pain that affects performance of our HT based applications. I think that load factor and decision to rehash, grow size up etc… are based on this count property. this seems to me that the poor performance after several minute of running my algorithm come from this issue.

I will try other test tomorrow…


#12

The full source code for Hashtable is there. Just take it, apply the fix and use it until it makes into the official release.


#13

Hello Architect

I do not even know how to do that!!! Does this mean that I can take HashTable.cs and put it into a directory to make it work? I believed that .netmf should be recompile and linked with GHI proprietary dll or code to obtain a GHI flavour .nemtf SDK…

Do you have any pointer on how to do it?


#14

It is very simple actually. Similar to creating a new class from scratch,only all the code is already written for you

  1. Just copy the code of the whole class (including any helper classes it requires) from the link you have provided (codeplex).

  2. Paste it into a new empty c# file in you project. Change the namespace to something else,so there is no conflict with the system Hashtable.

  3. Compile and use it in you code.


#15

This seems so obvious that I couldn’t believe it…

Great I will try that tomorrow morning!!!

Many thanks


#16

You are welcome ;D