chorg has asked for the wisdom of the Perl Monks concerning the following question:

So, I've heard that method calls are expensive. I understand the whole run-time resolution vs compile time stuff, and all that, but I'm now thinking in a more philosophical vein:

Usually, when I write object methods, I make my methods pretty simple and small. I make each one model a single action, ie:

Add to cache

Check Cache for this value

Email me if Wiggy Wuggy tries to use this program

etc...

So I am wondering, to write more efficient, faster OO code, should I try and put more into each method, so that I need to call them less?
_______________________________________________
"Intelligence is a tool used achieve goals, however goals are not always chosen wisely..."

Replies are listed 'Best First'.
(Ovid) Re: Method calls expensive??
by Ovid (Cardinal) on May 05, 2001 at 01:44 UTC

    Why do you want to write faster code? Is this just a general want, or is it an issue directly affecting what you need to accomplish? Efficiency is nice, but so is clarity. Personally, if I have the luxury, I will always sacrifice speed for well designed, clear code.

    Personally, I wouldn't try to put more in one method. The more things a particular method does, the more likely it is for things to go wrong and for you to have maintenance issues. For example, if you have a method that establishes your database connection, you may think "ah, they're starting a session, so I'll just pack all of my other session initialization code in the db->connect method". All that is well and good, until the day that you need to establish the database connection without starting a session. Then what do you do? Rewrite your code base? Create another connection method and thus have duplicate code which needs to be synchronized? Keep the methods simple, and you'll be happier in the long run.

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
      I agree with Ovid. Design your code well first. You'll probably save more time in maintenance programming than you give up in run-time.

      If you need to optimize later, find what small percentage of the code does the program spend a large percentage of it's time in. Then optimize that. You'll get the most bang for the proverbial buck.

[reply]
      Thanks for the replys all! What I am trying to do in general is work out some techniques that will make my coding style more efficient on the first pass, without sacrificing the readability and flexibility of OOP. I am writing code that has to deal with more traffic and more load than I used to, and adding more memory, or more processors is not an option for me in this environment - ie: It might get done, but not when I ask. So I'd like to keep these issues in mind when I am coding, so that I don't have to come back to optomize as much , if I have to, or use C ++ or something like that.
      _______________________________________________
      "Intelligence is a tool used achieve goals, however goals are not always chosen wisely..."
[reply]
Re: Method calls expensive??
by Masem (Monsignor) on May 05, 2001 at 01:44 UTC
    Method calls tend to be expensive only when you pass by value, and the program has to duplicate that information into the local copies. It's much easier to use references for anything beyond a scalar to reduce this copy time; even use scalar references if you know the scalar contains a large amount of data. Of course, you must then keep in mind that the data can be altered if passed by reference; in some cases, this is good, others bad.

    It is always better to reduce the OO functionality to the smallest possible and reasonable task as you can, so several smaller functions will be more maintainable and adaptable then monolith functions.

    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
[reply]
Re: Method calls expensive??
by Rhandom (Curate) on May 05, 2001 at 02:23 UTC
    All the comments above are good to listen to. Ovid makes some good points.

    I have noticed the following when I have been in a situation where using objects or not using objects would both fit the situation. From what I have seen, method calls are 15 to 20 percent slower -- but that is just the call. If actually calling your function or method accounts for only 1 percent of your program execution time, then it really doesn't matter. If you are doing something in a tight loop, then method calls might get to be heavy. However, even in this situation you could use Memoize (ala Dominus) with an intermediate sub, to lighten the method calls for you.

    In the end, inheritance, extensibility, cleanliness, and functionality seem to overcome any problems that there might be with speed.

    my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]
Re: Method calls expensive??
by dws (Chancellor) on May 05, 2001 at 02:39 UTC
    So I am wondering, to write more efficient, faster OO code, should I try and put more into each method, so that I need to call them less?

    This brings to mind the old saying

    It is easier to making a correct system run fast
    than it is to make a fast system run correctly.
    Strive first to make your code work correctly, and don't concern yourself with speed at an implementation level until you have a system that works. Choose a design that is appropriate to your performance requirements, then focus on implementing it correctly. If that means a few big methods, use big methods. More likely, you'll find that smaller methods are easier to understand and test. Then profile and tune.

[reply]

Back to Seekers of Perl Wisdom