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.

My real problems listing is stuff that in an ideal world would never be discovered after the fact, but in the real world frequently is.

As for your whoa, you read correctly. If I am setting up a hash with 100 elements that I expect to access a million times, the cost of returning it as a list may indeed be outweighed by the fact of looking up that reference a million times.

Continuing on, garbage collector? What garbage collector? You didn't know that Perl has no garbage collector? It uses reference counting, and if you create circular references, that is your problem. Oh, and last I heard the only OS under which Perl actually returns memory to the OS is the Macintosh.

As for the benchmarks, you are talking to the wrong guy if you expect me to care. I routinely put in run-time checks that get called every time my function runs and verify that the argument list really did make sense. This makes my code easier to develop, and for what I do debugging time is worth more than computer time.

If you really care about performance, Perl is the wrong language. It is fast for an interpreted language, sure, but compared to C it is pathetic. I mean, in C you don't waste time doing such silly things as worrying about whether or not your string is too large and needs to be moved to somewhere it has more room, no you just let them quickly overflow that buffer!

Really, my opinion on optimizing is that it is like running. If you are so eager to run that you start flailing your feet, you will fall over. First make sure you are upright and moving...

For the most part (as usual) I agree with tilly here. wantarray is generally the best way to do things, that gives you ultimate flexibility. And there are definitely times when returning a list instead of a hashref is good.

However, I have three minor quibbles.

• I'm not convinced by the argument that dereferencing can eventually add up to be costly enough. Use aliasing, and you really get the best of both worlds.

  sub f { %hash = (1,2,3,4); return \%hash }
  *my_hash = f();
  $my_hash{1}++;
  [download]

  No dereffing necessary, you have the speed of passing a reference combined with the speed of direct hash access.

• Refcounting is garbage collection. It may do some things suboptimally, but it's no less garbage collection than mark-and-sweep, etc.
• Perl is not an interpreted language.

-dlc (sans acidic tone ;-) )

Really, my opinion on optimizing is that it is like running. ...

And many agree with you, to quote Knuth: 'Premature optimization is the root of all evil' :)

Code should be optimized for readability first. Then if a performance problem occors, locate the source of the problem and optimize only that part of the code. As another saying goes, the processor usually spends 99 percent of its time in 1 percent of the code.

Have Fun

I like your acidic tone. It makes me think better. What you describe as the reference counter is most certainly the garbage collector. I've done the reading, I know that. Yes, MacOS is currently oen the few OSs whose memory manager actually decides whether to purge, move, allocate memory and return RAM to the system. Nifty huh? I actually don't care about the benchmarks either. Perl is one the faster interpreted languages and...cliche, cliche, cliche. oh well. im bored with this commentary, i don't actually see what we're arguing about. By the way, if you consider a "real world discovery after the fact" then most of the program will need to be rewritten, not just a return statement. oh well. that's all i have to say. thanx for the info on your program.


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