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.

AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.

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.

Hmm. I don't recall ever making the statement that your code was dangerous. You misunderstood "above". Your "real problems" listing is simply programming design which, as I said before, should be taken care of before actually programming. Therefore, when one does get to a line with a return, one is not worrying about "real problems" but whether or not such and such an optimization will prove effective.

Whoa there! Did I just read that a reference may be slower in the long run than copying hordes o' data? Perhaps on the order of ten elements this may be true (while this does not hold for C for obvious reasons) but for the example that we are supposed to be discussing, this will not be case (potentially large hashes). That's enough to warrant concern. You should also be careful with wantarray. A newbie may have problems with this since it the long run, it IS better to reference returns. If you don't, you are automatically guaranteed two copies of the same hash until the garbage collector finds the original- an obvious waste of resources. Imagine a poor PC user with already wasted resources dealing with bloated CGIs. That doesn't make anyone happy, especially since Windows doesn't return memory blocks to the OS (surprise! surprise! some OSs DO!) While agree that the return in your case is valid (since it needs to create the new memory and it doesn't matter where its malloc()'ed but this is still a very limited case. Perhaps we need to bring in Bob Barker with his Benchmark Showdown!:-)


AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.