Doc:2.6/manual/Game Engine/Performance/Display/Framerate and Profileのソースを表示

=Framerate and Profile= 

[[Image:(Doc_26x_Manual_Game_Engine_Performance_Display_Framerate_and_Profile)_(Framerate_and_Profile_During_Game_Execution)_(GBAFN).png|frame|right|Framerate and Profile shown at the game execution]]

Many people are familiar with the “Show Framerate and Profile” option in the BGE and the mess of text it displays on their screen. However, not as many people truly know what the different statistics mean. This article aims to help improve people’s understanding of the profile stats and how to change your game to get those numbers down (less time spent is better for performance). Aside from the FPS, the profile shows nine stats: Physics, Logic, Animations (only in newer versions of Blender), Network, Scenegraph, Rasterizer, Services, Overhead, Outside. To get the most accurate readings, I recommend turning off “Use Frame Rate” and using your graphics card drivers to force vsync to be off.

==Frametime==

This represents the total ammount of time spent in all of the calculations Blender is doing during the game plus the time spent to draw the game viewport. It will also show the actual framerate for the user. 

==Physics==
This represents the time spent on physics code. These days the BGE only uses Bullet for physics, so this stat mostly represents the time spent in Bullet. To reduce the time, you’ll need to simplify your physics so Bullet doesn’t have to do as much work. This can include using simpler physics shapes for objects. For example, if you have a complicated mesh for a character and you set the physics type to Convex Hull or Triangle Mesh (the default if no other bound type is explicitly set), Bullet has to do physics calculations with the complicated mesh, which is just a waste of time. Instead, try to see if something simpler like a sphere or box can do the trick. If not, at least setup a “proxy” by creating a simple version of your mesh that is invisible and is used for calculations instead of the complicated mesh that is used for rendering.

==Logic==

Time spent on logic is time that is spent on logic bricks and Python code (excluding code run through KX_Scene.pre_draw and KX_Scene.post_draw; those times show up under the Rasterizer). If you want to reduce this, you’ll need to simplify/optimize your logic bricks and Python code. I’m not going to give a tutorial on optimizing Python code, but [https://blip.tv/pycon-us-videos-2009-2010-2011/introduction-to-python-profiling-1966784 this talk] by Mike Fletcher (known for PyOpenGL) describes profiling Python code and some tips for optimizing. Remember, always profile your code before attempting to optimize it! As a last resort, you can also try moving some of your Python code to C/C++.

==Animations==

Under animations you have the time spent in Blender’s animation code, which the BGE makes use of. This includes things such as looking up pose data and interpolating key frames. However, be warned that sometimes things like calculating IK can show up under the scenegraph when calculating bone parents. Also, this category does not include the time spent to do the actual mesh deformation, this time is recorded under the Rasterizer category. To reduce the time spent on animation try to reduce the bone count in your armatures. You can also try switching your armatures over to iTaSC (set to simulation) for IK solving instead of the Legacy solver. iTaSC can be faster than the Legacy solver. In my tests I’ve seen 1.25~1.5x speed improvements when using iTaSC, but I’ve heard that 4x is not unreasonable.

==Network==

This might come as a surprise to some, but the BGE actually has some networking code. However, this feature was never really developed, so now it is mostly a stub that can send messages over a loopback interface. This is how Message actuators and sensors (and the corresponding Python API features) work. It’s doubtful that this category will ever be a time sink, but if you’re having problems, take a look at the number of messages you’re sending and see if you can reduce them.

==Scenegraph==

The scenegraph keeps track of objects’ position, orientation and scale (and probably a few other things I’m not thinking of at the moment). This also includes updating parent-child relation ships (e.g., bone parents). As mentioned earlier, the time for bone parents can include getting updated pose data, which possibly means calculating IK. If the scenegraph is really high, try reducing the number of objects in your scene. You can also try using iTaSC (mentioned under Animations). The scenegraph also handles culling (frustum and occlusion) calculations.

==Rasterizer==

The rasterizer is responsible for actually rendering the game. This includes rendering geometry, shaders, and 2D filters. Since the BGE makes use of double buffering, the rasterizer also has to swap the buffers, which can give really high readings if vsync is enabled (SwapBuffers() blocks while waiting for a screen refresh). To reduce the time spent in the rasterizer, you can try to simplify your geometry and materials. Also make sure you don’t have too many lights casting dynamic shadows. Each shadow cast requires the scene to be rendered. So, if you have three spot lights casting shadows, the scene is rendered four times (three for shadows and once for the actual scene)! 2D filters can also suck up some time, so even if that bloom, depth of field and SSAO look nice, you might want to consider removing them or trying to reduce the number of samples they use.

==Services==

This is the time spent processing various system devices (keyboard, mouse, etc). You shouldn’t have a problem with this category taking up time.

==Overhead==

This is probably one of the most mis-leading category names. The “overhead” is all the text drawn on top of the game screen in the top left corner. This includes the framerate, profile, and debug properties. So, the time spent on this category should be reclaimed when running your game in a more “release” configuration (i.e., you’re not drawing all that debug/profiling text to the screen). If you want to reduce the time spent here while profiling, try reducing the number of debug properties you display.

==Outside==

This is time spent outside of the BGE’s main loop. In other words, something is taking time away from the BGE. You really have no control over this area. If you have a lot of other programs running, you can try to close some.

{{clr}}

{{NiceTip|1=The texts present at this page are an exact copy of Mitchell Stokes ([[User:Moguri|Moguri]]) blog.|2= The  original texts are located [https://mogurijin.wordpress.com/2012/01/03/bge-profile-stats-and-what-they-mean/ there], we were in contact with the author and he gently allowed a free copy of his texts, asking us to maintain his page reference.}}