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.
