in reply to Re: Re: Managing Client Specific Hashes
in thread Managing Client Specific Hashes

63 elements is not much. Determining which method to load the hash is the fastest isn't worthwhile (unless you want to load thousands of them).
When I say the hash is sorted I mean the keys are sorted when I use it.
What do you mean by that? Does that mean you always sort the keys, and access the hash using the sorted keys? In that case, it looks like you shouldn't use a hash, but a sorted array instead.

Abigail

Replies are listed 'Best First'.
Re: Re: Managing Client Specific Hashes
by Grygonos (Chaplain) on Jan 13, 2004 at 15:49 UTC

    In my mind its bad to have arrays with 'willy-nilly' indexes... such as:index 9 is valid.. index 31 is valid... but 10 through 30 are not...this is bad practice correct? and yes they are always sorted when I use them. I would be sorting the array by index and not value... I'm not understanding why you think an array is a viable option... please explain that.. I would like to understand.

    Grygonos
[reply]
      I would be sorting the array by index and not value... I'm not understanding why you think an array is a viable option... please explain that.. I would like to understand.
      So, you are sorting the array (I think you mean the list of keys here), but you don't think an array is a viable option? Storing the data in a sorted array instead of storing them in a hash, and sorting it before usage, eliminates a step.

      Abigail

[reply]
        but the key is important data as well... the key is where the data field begins... and that hashes to how long the field is... can you present a sample array that does what you propose? Thanks if you have time.
        Grygonos
[reply]

In Section Seekers of Perl Wisdom