If AAs don't have any hidden penalty, like causing the garbage collector to thrash, then that's the way to go
Any time you insert an item into an AA it might allocate. So it might cause a garbage collection cycle. I'm unsure what you mean by "causing the garbage collector to trash" memory leeaks? If it's not acceptable that the gc will collect then either build a custom hash map class with determenistic memory
management or implement your sorted array version.
Note: Lookup into AA's does not allocate
I've used larger AAs in simple programs without problems, but this one will probably run continually for months.
I have never written anything that is supposed to run for months at a time so take anything i say with a grain of salt.
is only one piece, so I'm a bit concerned about things that I can't see any easy way to test. So I thought I'd ask. P.S.: The external codes are NOT known at compile time. Not even at the start of run time. They are added incrementally, and there is no actual rule about what they will be. (This is a part of the reason for all the "about" and "estimated" in my original statement (unless I edited them out).)
Since the codes have no rule the best you can do for an hash function is to use a gernerall one, this might not be good enough for your purposes. You could test it with the build in string hash function on random strings of a specific length but it's no guarantee that it will work well for you specific data. It's however highly likely that it will still be faster then 15 misses to 1 hit ratio.
So it sounds like I should plan on using AAs, and just keep the array option around as a fallback position.
I would aggre. If the extra memory and non-deterministisism is not acceptable go with the array.
