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

That was a sample, the real hash is 63 elements.. nothing enormous.. but yes bigger than 11. When I say the hash is sorted I mean the keys are sorted when I use it. I know the hash itself is never really sorted.
Grygonos
  • Comment on Re: Re: Managing Client Specific Hashes

Replies are listed 'Best First'.
Re: Managing Client Specific Hashes
by Abigail-II (Bishop) on Jan 13, 2004 at 15:37 UTC
    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

[reply]

      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]

In Section Seekers of Perl Wisdom