Charles Hixson wrote in post #1084133:
> Hashes are slow compared to direct indexing.

Says who?

> Push might be a good
> answer, but not if it allocates storage item by item.

It doesn't. Look at the MRI C implementation if you really care: the 
underlying array storage size is increased in chunks. Ditto for Strings.

void
rb_ary_store(ary, idx, val)
...
    if (idx >= RARRAY(ary)->aux.capa) {
        long new_capa = RARRAY(ary)->aux.capa / 2;

        if (new_capa < ARY_DEFAULT_SIZE) {
            new_capa = ARY_DEFAULT_SIZE;
        }
        if (new_capa >= ARY_MAX_SIZE - idx) {
            new_capa = (ARY_MAX_SIZE - idx) / 2;
        }
        new_capa += idx;
        REALLOC_N(RARRAY(ary)->ptr, VALUE, new_capa);
        RARRAY(ary)->aux.capa = new_capa;
    }

[from ruby-1.8.7-p352/array.c]

> Allocation of memory is another expensive operation

Says who? Expensive compared to all the other things going on in your 
program? Your program will probably be creating objects 
left-right-and-centre, and having them garbage collected too.

I think you are approaching this the wrong way. I suggest you first 
write some code that works, using the most simple and logical code. 
*Then* optimise it if required: and optimise by measuring. Even for 
experienced programmers, usually the hot-spot turns out not to be where 
they guess it might be. And as you have already implied, you might need 
to optimise for memory usage over speed.

From a speed point of view, I'm pretty confident in saying that the 
implementation of Hash (in C) versus the implementation of Array (in C) 
is unlikely to be the bottleneck in your program. An Array may use less 
memory than a Hash - but since the Array or Hash holds only object 
references (essentially pointers), both may be small compared to the 
memory allocated to the objects you are holding within them.

-- 
Posted via http://www.ruby-forum.com/.