|
dspencer
|
 |
« on: June 06, 2009, 08:01:46 AM » |
|
Hey, For the first time in my computer programming career, it has become relevant to find where my game is bottlenecking. Can anyone give me any advice on a good way to do this? Should I just stick timers in every function and add a static variable and get the average time it takes? Or is there a program that can help figure this out?
thanks!
|
|
|
|
|
Logged
|
|
|
|
|
ஒழுக்கின்மை
|
 |
« Reply #1 on: June 06, 2009, 08:04:13 AM » |
|
usually it's not a function execution speed, but rendering speed (fill rate) that bottlenecks a game. what you could do is selectively turn off parts of the game that are drawn, have triggers that toggle, say, the background, or shadows, or whatever, on and off individually, and from that you can determine what it is that you're drawing that slows down the game the most.
|
|
|
|
|
Logged
|
|
|
|
|
moi
|
 |
« Reply #2 on: June 06, 2009, 08:24:23 AM » |
|
-toggle off methods and objects until the game starts working nice again. -toggle the other items back on to be sure what is causing the bottleneck
|
|
|
|
|
Logged
|
subsystems subsystems subsystems
|
|
|
|
raigan
|
 |
« Reply #3 on: June 06, 2009, 09:05:30 AM » |
|
Depending on what language/platform you're using, there should be some profiling tools which will show you where the processor and memory is being used. The demo version of JetBrains dotTrace works great if you're in C#.
|
|
|
|
|
Logged
|
|
|
|
|
increpare
Guest
|
 |
« Reply #4 on: June 06, 2009, 09:08:52 AM » |
|
Hey, For the first time in my computer programming career, it has become relevant to find where my game is bottlenecking. Can anyone give me any advice on a good way to do this? Should I just stick timers in every function and add a static variable and get the average time it takes? Or is there a program that can help figure this out?
thanks!
using a profiler is the easiest way. for instance, gprof if you're using C/C++ and interested in code speed. If you want to investigate graphics speed and are using opengl, there's a native opengl profiler on osx, and on windows there's gdebugger (there's a free trial version there), and there're a couple of other things as well IIRC. There're similar tools for DirectX, but I'm not a DX person, so. a lot of people turn to timers first though; it can be hard to profile some parts of code in isolation in some stuff. anyway.
|
|
|
|
« Last Edit: June 07, 2009, 06:10:16 AM by stephen lavelle »
|
Logged
|
|
|
|
|
BorisTheBrave
|
 |
« Reply #5 on: June 06, 2009, 02:40:35 PM » |
|
Using a profiler is the ONLY way. You cannot measure bottlenecks by printing time information, as that instrumentation frequently changes the results signficantly. And don't try to guess, either, that only works in a well established system, and then it can still trip you up.
Timers are appropriate for measuring overall speed levels, say you want to measure the improvement of a change, but that's not so sueful.
|
|
|
|
|
Logged
|
|
|
|
|
xiotex
Guest
|
 |
« Reply #6 on: June 09, 2009, 03:31:44 AM » |
|
The best way to find out if your game is fill rate or cpu bound is to reduce your render viewport to as small as you can make it. If your ms per frame is still way too high then you are CPU bound.
|
|
|
|
|
Logged
|
|
|
|
Alex May
...is probably drunk right now.
Level 10
hen hao wan
|
 |
« Reply #7 on: June 09, 2009, 03:33:10 AM » |
|
Or pause your game logic but still perform the render.
|
|
|
|
|
Logged
|
|
|
|
|
xiotex
Guest
|
 |
« Reply #8 on: June 09, 2009, 03:37:11 AM » |
|
Or pause your game logic but still perform the render.
Yeah, that's usually a good approach too except certain devs I know mix logic and render in the same functions 
|
|
|
|
|
Logged
|
|
|
|
Alex May
...is probably drunk right now.
Level 10
hen hao wan
|
 |
« Reply #9 on: June 09, 2009, 03:40:05 AM » |
|
heheh dear oh dear 
|
|
|
|
|
Logged
|
|
|
|
|
bengarney
|
 |
« Reply #10 on: June 11, 2009, 02:58:17 PM » |
|
Using a profiler is the ONLY way. You cannot measure bottlenecks by printing time information, as that instrumentation frequently changes the results signficantly. And don't try to guess, either, that only works in a well established system, and then it can still trip you up.
If you are measuring broad things (like "how long did collision for this whole tick take") then you can use pretty crude instrumentation. But if you're sampling more than a hundred points or so you will start seeing some serious overhead and the profiler will be more useful.
|
|
|
|
|
Logged
|
|
|
|
|
MrChocolateBear
|
 |
« Reply #11 on: June 13, 2009, 12:27:34 PM » |
|
If you are measuring broad things (like "how long did collision for this whole tick take") then you can use pretty crude instrumentation. But if you're sampling more than a hundred points or so you will start seeing some serious overhead and the profiler will be more useful.
I don't think it's so much about timers being bad, it's more about picking the right instrument(s) for what you want to do. Timers are awesome, but they only give you one kind of profile. If you are serious about optimization, you need to take more information in to account when determining what your "bottlenecks" are. A few of the things you will want to consider, not even discussing rendering, are a given function's memory footprint, time to call (time spent in the function), and sub-calls (functions called inside another function). Its a lot of information to deal with an analyze, but its essential to squeezing out every drop of performance you can.
|
|
|
|
|
Logged
|
|
|
|
|
Melly
|
 |
« Reply #12 on: June 19, 2009, 03:22:32 PM » |
|
would anyone know if there's a way to do profiling in AS3/Flash10?
|
|
|
|
|
Logged
|
|
|
|
|
Chris Z
|
 |
« Reply #13 on: June 19, 2009, 03:45:12 PM » |
|
dspencer, what platform/graphics API are you using? For DirectX/XNA apps you can use PIX which has several modes that have helped me many times in the past. It lets you take single frame captures of API calls, data over time, and a real-time overlay with a lot of nifty data on draw/set/create calls.
For anything else, and assuming you're working in 3D or through an engine/API that is HW accelerated, you can get vendor specific profiling tools from nVidia and ATI (PerfHUD, etc.).
This is assuming your bottleneck is on the graphics side and not in collision and AI. I wish I could give you some good sources, but I'd recommend doing a quick search on profiling. A basic profiler is pretty simple to write and instrument your code with (ideally in #ifdef DEBUG blocks).
EDIT: A quick runthrough of the algorithms in some of your obvious performance impacting subsystems will help too. For example, checking if you're doing more collision checks than you need to, taking advantage of early-outs whenever possible, caching results, etc. Cache coherency is also a big problem sometimes, for example for particle systems you should try to preallocate a ring buffer of particles rather than allocate them on the fly since that will destroy your cache. Make sure you're not constantly randomly accessing memory that is obviously non-adjacent, such as in scene traversal for collision and rendering.
|
|
|
|
« Last Edit: June 19, 2009, 03:52:44 PM by IceNine »
|
Logged
|
|
|
|
|
MrChocolateBear
|
 |
« Reply #14 on: June 20, 2009, 04:13:51 PM » |
|
would anyone know if there's a way to do profiling in AS3/Flash10?
As far as I know there are no widely used profilers for AS3, although my knowledge in this area is limited. It shouldn't be too hard to create a simple FPS counter and timer in AS3 and make optimizations based off that. I've seen a few guides on the internet for FPS and timer calculations, so if you run in to any trouble, I can link you to a few. Hopefully someone else on the forums knows more about AS3/Flash specific optimization and can help you further.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
bateleur
|
 |
« Reply #16 on: June 21, 2009, 01:37:07 AM » |
|
-toggle off methods and objects until the game starts working nice again. -toggle the other items back on to be sure what is causing the bottleneck
This is the approach I favour in the absence of a good profiler. One additional trick which can help a lot is if you have a section of code which can't be switched off without breaking your program, try running it multiple times instead.
|
|
|
|
|
Logged
|
|
|
|
|
MrChocolateBear
|
 |
« Reply #17 on: June 21, 2009, 03:35:46 PM » |
|
Doesn't this only work with Flex apps though? If it works for AS3/F10 in general, I could see it being rather useful.
|
|
|
|
|
Logged
|
|
|
|
|