in reply to RE (tilly) 2: Load Balancing fun..
in thread Load Balancing fun..

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.

AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.
  • Comment on RE: (AgentM) RE (tilly) 2: Load Balancing fun..

Replies are listed 'Best First'.
RE (tilly) 4: Load Balancing fun..
by tilly (Archbishop) on Oct 03, 2000 at 00:40 UTC
    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]
      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.
[reply]
[d/l]
        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...

[reply]

In Section Cool Uses for Perl