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;
}
}
c++ Am I right about this... speed question
Author
Hi, I just did a speed test on getfunctions
eg:
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?
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?
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...
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...
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.
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.
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.
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.
Quote:Original post by sjelkjd
worst thread ever...
C++: Now with extra-large spoiler and Type-R sticker!
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
