Associative Array: reasonable limits?

[TheFlyingFiddle]

On Saturday, 2 November 2013 at 23:58:07 UTC, Charles Hixson 
wrote:
> On 11/02/2013 04:49 PM, TheFlyingFiddle wrote:
>> What are you going to be using the collection for?
>>
>>
> It's basically a lookup table used for translating external 
> codes (essentially arbitrary) into id#s used internally.  There 
> are LOTS of id#s that don't correspond to ANY external code, 
> and nearly all the processing is done only using those id#s.  
> The codes are used only during i/o, as they are more 
> intelligible to people.

Well if the codes are only used during i/o the performance of the 
collection is not rly that important. Since the bottleneck is the 
i/o anyways.

Saying that my recommendation is to go with the AA since it's rly 
simple to work with. It also has the benefit that if you have a 
good hashing function lookup time will generally be O(1). Also 
this eleminates the need for building a custom datastructure.

It is my understanding that there are no hard limits on the 
number of elements in the built in AA.(But i canno't say for 
sure, it's very simple to test though).

Since the collection is never going to be deleted. If the 
external codes are known at compiletime i would recomend you to 
generate the collection at compiletime thus avoiding the runtime 
cost of building the table. (This works for either AA or Sorted 
Array) Also this eleminates the need to care about insertion 
times (unless you get unreasonable build times ofc ^^).

Hope this helped a little. Its hard to say if AA or SA is the way 
to go without profiling the complete application.