From: Hal Fulton <hal9000@...>
Date: 2006-08-14T07:29:39+09:00
Subject: Re: A use case for an ordered hash

Phillip Hutchings wrote:
>>
>> Anyway: I'm happy that lookups are fast. But 99% of the time,
>> my hashes are small enough that the time savings is probably
>> very small in terms of program execution time.
> 
> Unfortunately for you some of us do things that involve searching
> through 30,000 sales records to pull out Joe Bob's statistics.
> Sometimes you just don't want to do that on the production database,
> it just uses far too many resources. Using an ordered hash for one
> person's benefit would kill the speed and jack up memory usage.

Your point is well taken.

However, it remains to be seen whether it would kill the speed.
Personally I doubt it would be significant, but I've seen no
numbers one way or the other.

Memory I would consider a more serious issue. Every pair in the
hash would occupy an extra N bytes (addmitedly a low value of N,
like 4). In the case of 30,000 pairs, that's an additional (say)
120K of RAM used.

As for "one person's benefit" -- it's true that the people
wanting this functionality are in the minority. But we are
far more than one person. :)

> I know an ordered associative array (which I think is a better
> description of the functionality) would make some things very easy,
> but replacing the Hash is not the way to go.

That is definitely a better description of the finctionality.

I would even say that "associative array" alone would be a sufficient
term, since "array" implies order. (But I may be wrong there.)

I'd be happy with a separate class for that functionality *IF* there
were a convenient notation for literals. (For example, the combination
of square brackets and arrows that I mentioned previously, which Ruby
currently interprets as an array with a single element which is a hash.)

Without the literal notation, it would be to me just another kludge.


Hal