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?
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.
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?
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 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…