C# Developers' Journal (original) (raw)
1:18a
While I don't really understand where the last discussion was going, it did get me interested in performance and memory overhead of the hashtable. I have to use the hashtable a lot, so this one hits home.
I wrote a test app to see how much memory a hashtable uses. I put longs into a hashtable. ( m_objHT.add(i,null);)
No items in hashtable = 6880k
1000 items = 6968k ; time: momentary
10000 items = 7396k ; time: momentary
1000000 items = 52852k ; time: momentary
10000000 items (it struggled badly with this, I watched it realloc a couple of times, at least) = 329640k ; time: about 30 seconds.
If I exclude my baseline .Net Framework, it works down to:
Number of Items | bytecount | After removing framework | bytes per item | minus the size of the long included |
---|---|---|---|---|
1000 | 6968000 | 88000 | 88 | 80 |
10000 | 7396000 | 516000 | 51.6 | 43.6 |
1000000 | 52852000 | 45972000 | 45.972 | 37.972 |
10000000 | 329640000 | 322760000 | 32.276 | 24.276 |
For memory alloc, it doesn't look that bad at 1 mil and up, your overhead is decreasing exponentially, unfortunately so is the speed. 38 bytes of overhead an item at 1 mil, 44 bytes overhead at 10000 items (per item).
at 10000000 items , its only 24 bytes of overhead per item, but its REALLY slow to access anything.
On the lesser counts, its pretty quick, but your overhead cost is pretty high.
You could argue my numbers above that the .net framework itself takes up some memory. While I think this is true, and I would go along with that, you still have to account for it someplace.
You also have some room around system speed. I'm not working on a beefy box at all. P4m, 512 mb of ram. Done as a console app, to make it as small as possible.
What I want to know is, why does the overhead change? I would think it would be pretty static. Also, why the deep realloc on the 10 mil set? Any takers?