Sign in to follow this  

c++ Am I right about this... speed question

This topic is 4759 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I just did a speed test on getfunctions eg:
class Abc {
private:
   int value;
public:
   Abc(){value=0;}
   int getValue();
};

void main() {
   Abc abc;
   
   //This is way way way slower
   for(int i=0;i<10000;i++) {
      int v = abc.getValue();
   } 

   //Than this which is way faster  
   int gVal = abc.getValue();
   for(int i=0;i<10000;i++) {
      int v = gVal;
   } 
}

I was just testing this, and even if I use pointers instead, eg int v = *abc.getLpValue(); it is still slow, although using the pointer is slightly faster, but only so slightly. I was never aware of this(the code above) and I have sped up one of my programs heaps now. Anyone else aware of this, or think i'm wrong?

Share this post


Link to post
Share on other sites
It should be faster because the first time you're calling that function 10000 times or whatever, but the second you only call it once. the assignment is much faster then the function call cause the stack never leaves main. Not sure why you would do what you're doing here tho... a little more background maybe?

Share this post


Link to post
Share on other sites
I very much doubt returning an int is slower than returning and dereferencing a pointer.

I would rather investigate how you measure time, what special thing you do in the getter, what programs you are running in the background, if you run in debug mode etc...

Share this post


Link to post
Share on other sites
Quote:
Original post by johnnyBravo
Anyone else aware of this, or think i'm wrong?


I'm guessing that there's no real difference between using a pointer and not using a pointer. Did you test each way multiple times? The pointer method should be slower, unless the compiler's using some trick like caching the dereference, in which case they're likely the same and any difference is just random error. Another thing to note is that the compiler is able to completely optimise away the second loop: It's a no-op. Try declaring v outside both loops and as volatile. It can't optimise away the first loop because the function may have side effects (well, technically it can see the function in this case so it could see there are no side effects, but in general it can't).

In any case, this is a common technique for speeding up loops. Move expensive computations to the outside of the loop when possible. The compiler can't do this because it doesn't know if a function call might have side effects.

Share this post


Link to post
Share on other sites
Quote:
Original post by johnnyBravo
Anyone else aware of this, or think i'm wrong?

Function calls aren't cheap.

On a second note, redundant operations are usually a bad idea. Try to do as little as possible in the loops, keeping redundant stuff out of the loop.

Share this post


Link to post
Share on other sites
People always post speed tests where their code totally invalidates the results. You have done just the same.

Since you do nothing with "v" (heck it's scope is only within the for loop) the compiler could easily optimise it out.
The second version possibly isn't even executing any loop at all!

An excellent rule for making sure your speed test code is valid is this:

If it would be possible to take out a single line of code and have the program still produce the same result, then your test is flawed!

Now, rewrite yout test with that in mind, THEN post your results.
In fact, your program doesn't even have any output! At least print out the sum of all your getValue calls or something.

Also, always apply all optimisations. i.e. release build.

Share this post


Link to post
Share on other sites
Also look at the generated assembly. Most of these sorts of questions can be trivially answered just by looking at what the compiler generates.

This is why I tell people to learn assembly. Not because you're going to write it, but because it's really useful to be able to read it.

Share this post


Link to post
Share on other sites

This topic is 4759 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this