static void function_to_call(void)
{
}
static void copy_to_screen(SDL_Surface* surface, int width, int height)
{
SDL_LockSurface(surface);
for (y = 0; y < height; y++)
{
for (x = 0; x < width; x++)
{
function_to_call();
}
}
SDL_UnlockSurface(surface);
SDL_UpdateRect(surface, 0, 0, 0, 0);
}
Is this what you'd expect to happen?
Author
My frame rate drops from ~100fps to 10fps when I call an empty function once for each pixel in a 640x480 screen.
I'm going to take a stab in the dark and say that the loop itself is being optimized out by the compiler when it sees that it does nothing.
Even when calling an empty function, your computer still needs to iterate through 307,200 (640 pixels times 480 pixels) separate function calls each frame. Is it necessary to be checking each pixel individually like this?
Quote:Original post by SirSmokey
I'm going to take a stab in the dark and say that the loop itself is being optimized out by the compiler when it sees that it does nothing.
I don't know about other compilers, but I know that VC++ does that in release mode. I had this problem when doing some performance testing - looping a function I wrote 1,000,000 times. When VC++ saw that the loop doesn't actually affect anything (no variables changed, no output), it just threw away the entire loop.
Author
The compiler definitely isn't removing the function call. The frame rate is high when the function is commented out and significantly lower when it isn't commented out.
I was going to do some lighting calculations on each pixel with that function, but if this amount of slow down is to be expected from just calling an empty function, I don't think I'm going to have the processing power to do lighting calculations. Sort of why I'm asking if this degree of bog down is reasonable to expect is to determine if I should continue to pursue the lighting functionality at all or at least pare it down significantly.
I just found it a little unbelievable that the frame rate went down THAT much. I would have expected maybe a 40% or 50% drop at most, but not 90%.
I was going to do some lighting calculations on each pixel with that function, but if this amount of slow down is to be expected from just calling an empty function, I don't think I'm going to have the processing power to do lighting calculations. Sort of why I'm asking if this degree of bog down is reasonable to expect is to determine if I should continue to pursue the lighting functionality at all or at least pare it down significantly.
I just found it a little unbelievable that the frame rate went down THAT much. I would have expected maybe a 40% or 50% drop at most, but not 90%.
Hey there.
I would imagine this is a problem
static void copy_to_screen(SDL_Surface* surface, int height, int height)
parsing in "height" TWICE !!!
(Does this actually compile ??)
your for loop wont be doing much either, since "width" was never assigned
for (x = 0; x < width; x++)
As "width" is unassigned, it could be some massively high number also.
so you could be causing a massive loop, hence the drop in frame rate
;-)
I would imagine this is a problem
static void copy_to_screen(SDL_Surface* surface, int height, int height)
parsing in "height" TWICE !!!
(Does this actually compile ??)
your for loop wont be doing much either, since "width" was never assigned
for (x = 0; x < width; x++)
As "width" is unassigned, it could be some massively high number also.
so you could be causing a massive loop, hence the drop in frame rate
;-)
Author
LOL! Damn typos!
It is actually correct in the source file, I just copied it wrong to the forum. :o
I can confirm that the width and height are correct in the debugger.
Thanks though. :)
It is actually correct in the source file, I just copied it wrong to the forum. :o
I can confirm that the width and height are correct in the debugger.
Thanks though. :)
Hi again,
OK glad thats ok.
The only question I have then, is why the need for a function that does nothing ????
if you want to test it, just make the function do something, even if it's pointless, just declare a variable and assign is something.
static void function_to_call(void)
{
int i = 0;
}
... and personally I would specify that your loops are integers
(depending on your compiler)
for (int y = 0; ....
OK glad thats ok.
The only question I have then, is why the need for a function that does nothing ????
if you want to test it, just make the function do something, even if it's pointless, just declare a variable and assign is something.
static void function_to_call(void)
{
int i = 0;
}
... and personally I would specify that your loops are integers
(depending on your compiler)
for (int y = 0; ....
Quote:Original post by Kryptyglyf
The compiler definitely isn't removing the function call. The frame rate is high when the function is commented out and significantly lower when it isn't commented out.
Well what I meant was that when you comment out the function call, the compiler sees that inside the loop, nothing happens (no function call or anything) so it might remove the loop eniterly.
But if your in debug mode, then no optimizations should be happening... i think.
Author
I inserted:
and that took another frame off the frame rate. 11ms adding two instructions to the loop?
I don't need a function that does nothing. I actually had a function that did some lighting calculations, but the app was running at like 2fps so I started eliminating stuff to narrow down what was creating the hang up. It turned out to be a function inside the x,y loop. When I removed the function from the loop, the frame rate shot up to 100+fps, with the function ~7-8fps. So I started commenting out code in that function until there was nothing left but variable declarations only to find that I'm still running ~10fps. Then I created function_to_call(), had the same problem, played around with __fastcall, __inline, etc., scratched my head some, then posted here.
int i;i = 0;i++;and that took another frame off the frame rate. 11ms adding two instructions to the loop?
I don't need a function that does nothing. I actually had a function that did some lighting calculations, but the app was running at like 2fps so I started eliminating stuff to narrow down what was creating the hang up. It turned out to be a function inside the x,y loop. When I removed the function from the loop, the frame rate shot up to 100+fps, with the function ~7-8fps. So I started commenting out code in that function until there was nothing left but variable declarations only to find that I'm still running ~10fps. Then I created function_to_call(), had the same problem, played around with __fastcall, __inline, etc., scratched my head some, then posted here.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
