Cost of pushing variable onto stack

This is a discussion on Cost of pushing variable onto stack within the C++ Programming forums, part of the General Programming Boards category; Does anyone have a good reference for what it costs to use a local variable versus using the return value ...

  1. #1
    Registered User
    Join Date
    May 2005
    Posts
    22

    Cost of pushing variable onto stack

    Does anyone have a good reference for what it costs to use a local variable versus using the return value of a method call in C++?

    I hate using a string of method calls together in an equation, it makes it so unreadable. Yet if I use local variables to hold the returns of these calls, then use those variables in the equation, I draw the ire of certain guys in our department as being inefficient. Is it really that inefficient to push a few local variables on the stack simply to make a bit of code easier to read and understand?

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,433
    You might want to read about return value optimisations.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    It depends on your situation, but small inefficiencies are rarely important compared to making code clear and readable.

    If your department guys have profiled your application and found that the code you are modifying takes up the bulk of the time in your program, then maybe they have a point and you should use the most efficient method possible. Also, if you are being particular and picking one version over another simply based on personal preference and neither version is much clearer than the other, then again I'd say choosing the more efficient version would be better.

    Otherwise, I'd say stick to the clearer version. It'll save you and them more time on code maintenance in the future.

    Can you post an example of what youare talking about?

  4. #4
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,451
    The cost of
    Code:
    int foo ( void ) {
      return f1() + f2();
    }
    Compared to
    Code:
    int foo ( void ) {
      int a = f1();
      int b = f2();
      return a + b;
    }
    is negligible.

    For a start, the number of local variables doesn't matter. The compiler calculates the size of all of them, then in a single instruction generates the stack frame for the entire function.

    Second, a good compiler will simply optimise out redundant local variables which are there purely for readability.

    I agree with Daved, clarity is worth a lot in the long run, if all you're gaining is a few imaginary microseconds based on opinion rather than measurement.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  5. #5
    Registered User
    Join Date
    May 2005
    Posts
    22
    Quote Originally Posted by Daved View Post
    Can you post an example of what youare talking about?
    This is a rather mundane instance but shows what I'm talking about.
    Some variable names have been changed to protect the innocent!

    This, to me, is much more clear...

    Code:
    float zeroOrderTerm   = calInfo.getCoeff(mDir, CalibrationInfo::ZERO_ORDER_COEFF);
    float firstOrderTerm    = calInfo.getCoeff(mDir, CalibrationInfo::FIRST_ORDER_COEFF) * angleOfIncidence;
    float secondOrderTerm = calInfo.getCoeff(mDir, CalibrationInfo::SECOND_ORDER_COEFF) * angleOfIncidence * angleOfIncidence;
    
    float ref =  zeroOrderTerm + firstOrderTerm + secondOrderTerm;
    than this...

    Code:
    float ref = calInfo.getCoeff(mDir, CalibrationInfo::ZERO_ORDER_COEFF) + 
                           (calInfo.getCoeff(mDir, CalibrationInfo::FIRST_ORDER_COEFF) * angleOfIncidence) + 
                           (calInfo.getCoeff(mDir, CalibrationInfo::SECOND_ORDER_COEFF) * angleOfIncidence * angleOfIncidence);
    Plus, in debugging, it allows you to view the intermediate values of the calculation step by step.

    What I would really like to understand is what are the costs (overhead) of using stack variables. There's got to be some kind of document that someone has authored on the cost of pushing local variables on the stack vs. simply using a retrieved value directly.

  6. #6
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    You could also use:
    Code:
    float ref = calInfo.getCoeff(mDir, CalibrationInfo::ZERO_ORDER_COEFF);
    ref += calInfo.getCoeff(mDir, CalibrationInfo::FIRST_ORDER_COEFF) * angleOfIncidence;
    ref += calInfo.getCoeff(mDir, CalibrationInfo::SECOND_ORDER_COEFF) * angleOfIncidence * angleOfIncidence;
    Regardless, the difference between the efficiencies of the two versions will not be significant, so use whichever is clearer to you.

    I did some timing tests for fun, but didn't spend much time on it. There was no difference in my tests, and I doubt there would be a difference if you put them through something rigorous.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Stack Variable and Speed
    By babu198649 in forum C++ Programming
    Replies: 27
    Last Post: 01-12-2009, 10:42 PM
  2. Question about a stack using array of pointers
    By Ricochet in forum C++ Programming
    Replies: 6
    Last Post: 11-17-2003, 09:12 PM
  3. error trying to compile stack program
    By KristTlove in forum C++ Programming
    Replies: 2
    Last Post: 11-03-2003, 05:27 PM
  4. Stack manipulation
    By JJD in forum C Programming
    Replies: 1
    Last Post: 10-08-2002, 11:44 AM
  5. What am I doing wrong, stack?
    By TeenyTig in forum C Programming
    Replies: 2
    Last Post: 05-27-2002, 02:12 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21