Returning a hash can be very good. I basically did that in ret_tag_handlers in a recent post to good effect.
But if you think it matters, give a choice:
return wantarray ? %hash : \%hash;
Also worrying about low-level efficiency too much is a bad idea - real problems tend to be overall system design and algorithm choices. If you spend your time sweating details, you won't ever address the real problems... | [reply]
[d/l] |
Sorry, but I've got to disagree (somewhat) with your statement. In this case, the waste may not be impressive but such a mistake can lead to hard2debug code if you don't catch it quickly enough. The overall system design and algorithm choices are best made before putting fingers to the keyboard. Perhaps pseudocode or object-based organizers are good here. The actual coding is a focus on the "time-sweating" details. While I agree that wasting time on details may not get one anywhere, a typical error like FULL hash returns or array returns can lead to wasted resources and can ultimately lead to a bottleneck. Returned hashes may be useful in threads (as a workaround and definitely not a solution). C/C++ is a finely tuned instrument for making sure that such mistakes are not easily made. Perl, on the other hand, allows this as almost a sort of default (it's not obvious to the programmer that this is potentially serious). As I said, in the code above, there will be most likely no performance issue, but it's more useful to note bad programming techniques before they become serious.
I'm not exactly certain what you mean by "real problems". I would consider a bottleneck based on a single line of code very serious (although not above). If you mean debugging and testing to provide a final product, such coding will most likely not be caught by the debugger or tester and if the user decides to run 5000 of these load balancers than there is a potentially dangerous situation. Whenever i hear that word "potential" (let's say for a problem), I prefer to clean it up as best I can. A simple code alteration of two characters (as in the code above) will also be ultimately beneficial to all programmers since they see an learn from improvement. While you provide an example how you return an array in your sub, I don't fully understand the benefits of it in your example. A little more info on that would be nice. Thanks.
| [reply] |
If you are returning a hash and you will be using it heavily, you may get better performance if you return it as a hash and avoid the overhead of constantly dereferencing it. So the performance is 6 of one, a half-dozen of the
other.
As for the specific example that I directed you to, the return from that code is only part of a list that is used to construct a hash. By returning it as a list, rather than a reference, I am able to just put the entire function straight in the constructor.
The alternative that I suggested should satisfy both of us. In both list and scalar context it does something reasonable. You may consider doing different things in different contexts to be dangerous behaviour. I firmly disagree. Being context sensitive allows code to be both clear and concise. Perl is a member of the short and sweet school of maintainability.
Oh, as for real problems, try a database design where you do a query to get a list of record to work with, and then proceed down the list firing off queries on each record rather than having the original query do everything for you? Or how about having code that scans lists all of the time rather than doing hash look-ups? Or how about having a misconfigured firewall in front of your load balancer?
Those are all problems that gobble up orders of magnitude more performance than trying to make all of your functions return references rather than lists.
| [reply] |