We have a very versatile Collection class built into VB6 and we also have Scripting.Dictionary. Most of the time one or the other of these is all we need. But sometimes we have a special need for larger scale collections.
Scripting.Dictionary works well (if used carefully) up to 100K items or so. But beyond that point performance begins to degrade exponentially.
HashTub
A simple hash table where Keys are String and Item values are Variants.
A memory hog meant for very large tables (approx. one million or more entries, max about 18 million but less for Variant String items, Variant array items, etc.). Long key strings can also limit the maximum count. Most programs will do better using a Collection or a Scripting.Dictionary unless they need a huge table.
If you don't need Variants you can adjust to specific types (Long, String, some Class, etc.) and save on memory.
Assigning to an existing Item updates the Item's value. Item access is by key or index, indexes are base-1 like a Collection. A new item must be added by key.
No "insert" or "remove" operations.
Assign the Chunk property first. This should be 1/20 to 1/2 of the expected population. Larger is more wasteful, smaller is slower.
A better String hash might improve performance. Keys are case-sensitive and Unicode-aware. The current hash can accept ANSI Strings as well as normal Unicode Strings as keys.
HashTub is a fairly small class, 100% VB6 aside from one API call used for hashing.
Sample Run
![Name: sshot.png
Views: 116
Size: 3.6 KB]()
Requirements
Windows 2000, or earlier 32-bit Windows versions (including Win9x) with IE 5.0 or later installed. That is for the HashData() API call. If you substitute another hash it should work wherever VB6 runs.
Methods and Properties
Add NewItem, NewKey
Chunk [R/W]
Count [RO]
Exists(Key) [RO]
Key(Index) [RO]
Item(Index or Key) [R/W, write adds when Key is new]
Trim
Tweaks
Memory consumption can be reduced by changing the Item type from Variant to a specific type (String, Long, Currency, etc.).
You could also define a UDT in a static .BAS module and then you could use that as your Item type.
You can improve performance by dropping features. One is to drop access by Index. Then you will no longer need or have to update the NodeIndexes array. At that point the "Key" parameter can be passed ByRef and this speeds things up too.
You can also drop Object support even if you stay with Variant Items. That can simplify the code a little but gains little or nothing in performance. The capability isn't worth using though because creating a million or more Objects isn't a viable strategy.
Scripting.Dictionary works well (if used carefully) up to 100K items or so. But beyond that point performance begins to degrade exponentially.
HashTub
A simple hash table where Keys are String and Item values are Variants.
A memory hog meant for very large tables (approx. one million or more entries, max about 18 million but less for Variant String items, Variant array items, etc.). Long key strings can also limit the maximum count. Most programs will do better using a Collection or a Scripting.Dictionary unless they need a huge table.
If you don't need Variants you can adjust to specific types (Long, String, some Class, etc.) and save on memory.
Assigning to an existing Item updates the Item's value. Item access is by key or index, indexes are base-1 like a Collection. A new item must be added by key.
No "insert" or "remove" operations.
Assign the Chunk property first. This should be 1/20 to 1/2 of the expected population. Larger is more wasteful, smaller is slower.
A better String hash might improve performance. Keys are case-sensitive and Unicode-aware. The current hash can accept ANSI Strings as well as normal Unicode Strings as keys.
HashTub is a fairly small class, 100% VB6 aside from one API call used for hashing.
Sample Run
Requirements
Windows 2000, or earlier 32-bit Windows versions (including Win9x) with IE 5.0 or later installed. That is for the HashData() API call. If you substitute another hash it should work wherever VB6 runs.
Methods and Properties
Add NewItem, NewKey
Chunk [R/W]
Count [RO]
Exists(Key) [RO]
Key(Index) [RO]
Item(Index or Key) [R/W, write adds when Key is new]
Trim
Tweaks
Memory consumption can be reduced by changing the Item type from Variant to a specific type (String, Long, Currency, etc.).
You could also define a UDT in a static .BAS module and then you could use that as your Item type.
You can improve performance by dropping features. One is to drop access by Index. Then you will no longer need or have to update the NodeIndexes array. At that point the "Key" parameter can be passed ByRef and this speeds things up too.
You can also drop Object support even if you stay with Variant Items. That can simplify the code a little but gains little or nothing in performance. The capability isn't worth using though because creating a million or more Objects isn't a viable strategy.