• Advertisement
Sign in to follow this  

Do global variables slow down performance?

This topic is 1465 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 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.

Share this post


Link to post
Share on other sites
Advertisement

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 !

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement