Jump to content

  • Log In with Google      Sign In   
  • Create Account


Do global variables slow down performance?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 lonewolff   Members   -  Reputation: 426

Like
0Likes
Like

Posted 16 January 2014 - 10:23 PM

Hi Guys,

 

I am just making a renderer in directx for my game.

 

Initially my code was all inlined for testing purposes and I was getting a framerate of ~6000 FPS (Not practical I know).

 

But now I have started cleaning up my code and placing it all into appropriate functions.

 

For ease of use I made the D3DDevice global amongst half a dozen other things and now the framerate has dropped to only ~500 FPS.

 

I have stripped everything out of the main loop (and render loop) and only left my framerate counter (same as I used earlier) and I still get the reduced framerate. I have built in release mode, using the release DLL's.

 

But the only thing I can think of now is that the refernece to the global variables.

 

Is it possible that the globals are slowing things down?

 

Thanks in advance :)

 

Note: I will lock the framerate to 60 FPS when I have my framework sorted out, but I still want the logic to run as fast as possible.



Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 7025

Like
4Likes
Like

Posted 16 January 2014 - 10:45 PM

Please read this: http://www.gamedev.net/page/resources/_/technical/game-programming/performance-why-did-i-just-lose-100-fps-by-drawing-one-trianglesprite-r3242

 

A change from 6000 FPS to 500 FPS means you lost about 1.8 milliseconds of your frametime, which is very small and could have easily been caused by any one of the "half a dozen other things". Global variables generally do not make a difference in running time, it can go either way depending on your architecture, the structure of the code itself, and compiler settings, but it is often too small to matter in practice.

 

In any case, you should not worry about large changes to an absurdly high framerate. Until your framerate dips to less than 120 or so, you're in the green  and don't have to worry. And, please measure your frametime, not your framerate. Framerate is more difficult to interpret because it's not a linear measure of performance (as the linked article highlights).


"The best comment is a deleted comment."


#3 lonewolff   Members   -  Reputation: 426

Like
0Likes
Like

Posted 16 January 2014 - 10:50 PM

Thanks for the reply.

 

But, in this case the draw calls are identical to what I started with - A single draw_text function.

 

The only thing that has changed is that I am now wrapping code into functions etc.

 

So, I have lost 90% by just cleaning up the code?

 

BTW, I just checked in debug mode and debug gives me 20 FPS faster than release. I am only using release DLL's too.



#4 Bacterius   Crossbones+   -  Reputation: 7025

Like
4Likes
Like

Posted 16 January 2014 - 10:54 PM


So, I have lost 90% by just cleaning up the code?

 

That's what the article I linked addresses, and the reason you're confused here is because framerate is not linear. You have lost a lot of frame time compared to your original 6000 fps, but if you were running at, say, 100 fps, a loss of 1.8 ms of frametime would only bring you down to 85 fps. Losing another 1.8 ms would then bring you down to 73 fps. That 90% is a very small amount of time, it just seems huge because you're measuring in frames per second.


"The best comment is a deleted comment."


#5 lonewolff   Members   -  Reputation: 426

Like
0Likes
Like

Posted 16 January 2014 - 11:02 PM

But frametime is the inverse of framerate. And I am sampling over a 1 second period, so it should average out pretty much spot on.

 

Anyway, I just traced the issue. I had wrapped up too much of my draw text function, so it was being created, drawn, and destroyed on every loop.

 

6000 FPS has returned :)

 

So, where one person says 'dont worry about it', I have found a fundamental flaw in my code.  ;)

 

I fully understand that once you start adding game assets, the framerate will drop off in an exponential fashion and should settle around a few hundred FPS (as your link also points out).

 

Thanks again for your help though :)



#6 L. Spiro   Crossbones+   -  Reputation: 9733

Like
6Likes
Like

Posted 16 January 2014 - 11:48 PM

I fully understand that once you start adding game assets, the framerate will drop off in an exponential fashion and should settle around a few hundred FPS (as your link also points out).

Not according to this:

But frametime is the inverse of framerate. And I am sampling over a 1 second period, so it should average out pretty much spot on.


If you are running at 10 FPS and you lose 1.8 milliseconds, you are running at 9.8 FPS.
But if you are running at 1000 FPS and you lose 1.8 milliseconds, you are running at 357.1 FPS.

Wow! Big loss right?

Wrong.

You lost 1.8 milliseconds both ways.

 

Stop measuring in FPS.  Period.

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#7 lonewolff   Members   -  Reputation: 426

Like
0Likes
Like

Posted 17 January 2014 - 12:22 AM

Whatever way you want to look at it 1.8 milliseconds is a massive loss when we are talking about a CPU that can handle up to 3500000000 instructions per second / per core.

 

So yes - 'Big loss'.

 

Anyway as I said I found the source of the problem. So yes - the 'Big loss' was an unneccesary one.



#8 greenpig83   Members   -  Reputation: 289

Like
0Likes
Like

Posted 17 January 2014 - 02:10 AM

Yeah, fps look nice but it doesn't a good thing to measure performance! Use time is your choice!
Spiro is absolutely right :) and about speed, i did notice some spdeed down in calling function. For examle if u call a const function many times, if inside this func, u call another function (very simle that can be place inside the const function) then suddenly the speed go down !




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS