Ken Miller wrote:
>
> Well, if the keys are unique, you could just return a hashref, and then
> access it using sorted keys:
>
> foreach( sort keys %$HR ) {
> ## insert useful stuff here
> }
If only I could just use sort. :-) The order could be completely
arbitrary, based on search parameters, individual rankings, etc.
> >Are there any de-referenceing issues (performance wise) that would make
> >this less efficient than the 2 structures? TIA for any pointers.
My guess was that whatever overhead there was with de-referencing, it
would more than make up for it in the memory usage. And since I'm
running mod_perl with perl's malloc(), the extra memory doesn't get
returned until the child exists.
> Probably not, except your method takes more mems, since you're returning an
> extra array. 'Course, the sort takes mems as well, but not as much as the
> extra array.
>
> And, there is the overhead of sorting the keys.
> I think an array of hashref's is probably the best bet. Then you can use
> the DBs sort, and just build the array on the fly, once.
>
> For the site I'm working on, I return a reference to a ResultSet object
> which through the next() method returns the next row in the result set:
That is a very neat idea. From a logical point of view, I like it.
However, in my case that would be unnecessary overkill. I'll file it
away for future use. :-)
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
