OgreProfiler         Using the Ogre Profiler

This is a wikified version of the article by Amit Mathew originally found here.

Note on using with OGRE 1.7+

If you want to use this with a newer version of OGRE, you will need to download
 Plugin disabled
Plugin file cannot be executed.
, as it has been removed from the newer OGRE distributions.

IMPORTANT: These instructions are meant to be used with old releases of Ogre. For Ogre 1.10, rather see here.

Note on using with OGRE 2.1+

"OgreCore.zip" isn't needed. The packages you need are DebugPack.zip and profiler.zip which can be found in Samples/Media/packs
The CMake config has been renamed. It's no longer OGRE_PROFILING, but rather OGRE_PROFILING_PROVIDER. You must set it to "internal" to use the profiler discussed in this article.


Note: If you are using the Ogre SDK and you want to use the Profiler, it is advisable to switch to the source code version of Ogre, because the macro that switches the Profiler on or off (OGRE_PROFILING) is defined in OgreConfig.h and if you want to change this macro you also have to recompile Ogre. The SDK is shipped with OGRE_PROFILING set to 0, so Profiling is disabled by default.

First you want to initialize the Profiler like this:


This sets up the media that the profiler uses. The reason this is not in the constructor is because the profiler contains media dependencies that people who aren't using the profiler shouldn't have to worry about. The profiler will need you to specify the main program loop. To do this, you call the following at the very beginning of the frameStarted() function in your FrameListener class:

OgreProfileBegin("Ogre Main Loop");

and add this at the very end of the frameEnded() function:

OgreProfileEnd("Ogre Main Loop");

Make sure the names match exactly, otherwise the profiler will fail an assert. Next you want to profile some of your code. You do this by calling OgreProfile() and using braces ({}) to limit the scope. Note that OgreProfile cannot be called in the same scope as another OgreProfile(). Doing so will result in a compile-time error. Here is an example of using OgreProfile:

   OgreProfile("Collision Detection");
   mISQR = mISQ->execute();
   OgreProfile("Collision Response");
   SceneQueryMovableIntersectionList::iterator iter;
   for (iter = mISQR.movables2movables.begin(); iter != mISQR.movables2movables.end(); iter++) {
      // do stuff

If you want a profile to last outside of its scope, use OgreProfileBegin(<name>) and OgreProfileEnd(<name>) like you did when creating the main loop profile.

Reading the Display

On the left side are the profile names with a number in parentheses next to it. This number is the number of times this profile was called during this frame. If this number is 0, that means that the profile was called before, but is not being called currently. The bars on the left represent the frame time statistics. You can see indicators above which show that a profile can take anywhere from 0% to 100% of the frame time. The big yellow bars show the current frame percentage that the profile is taking. The green line shows the minimum frame time, the red line is the maximum frame time, and the blue line is the average frame time. Big discrepancies between the average and maximum can possibly be the sign of a performance bottleneck (however it could be the profiler acting strangely, see the Known Issues section). These results will be printed to the log when the application ends or you can manually do it by calling logResults().


Disabling the Profiler

You can disable the profiler by calling:


and enable it again by calling:


Note that this is a temporary solution. If you want to completely disable the profiler for your release version, see the section Release Version Considerations.

Disabling Individual Profiles

Disabling profiles can be useful if there are certain core functions that you want to profile on occasion. For example, you could profile certain rendering operations when you are checking general performance and then disable those profiles when you want to profile your AI code. You can disable a profile like this:

Ogre::Profiler.getSingleton().disableProfile("<profile name>");

and you can enable it again with this:

Ogre::Profiler.getSingleton().enableProfile("<profile name>");

Please note that trying to enable or disable a profile while that profile is running will have no effect.

Analyzing Application State

It is helpful to see the state of your application when a profile reaches a maximum level or some other condition. To check if a specific has reached a new maximum level, use:

Ogre::Profiler.getSingleton().watchForMax("<profile name>"); // return true if it reaches a new maximum

or to see if a profile has reached a new minimum level, use:

Ogre::Profiler.getSingleton().watchForMin("<profile name>"); // returns true if it reaches a new minimum

or to set an arbitrary level:

//returns true when AI code takes over 60% of the frame time
Ogre::Profiler.getSingleton().watchForLimit("AI code", .6, true);

//returns true when graphics code takes less than 10% of the frame time
Ogre::Profiler.getSingleton().watchForLimit("Graphics code", .1, false);

These functions should be used at the end of the main game loop for more accuracy. Otherwise, it will represent the results of the previous frame.

Logging Results

You can log the results of the current profiler statistics like this:


This is called automatically when you quit your Ogre application.

Changing the Frequency of Updating the Display

You can change how frequently the display is updated to suit your tastes like this:


Basically the tradeoff is between how accurate the display is and the amount of flicker. The default is that the display is updated every 10 frames.

Performance and Accuracy

I've tried to minimize the performance hit from using the profiler. However, like anything else, it still takes some time to perform the necessary calculations. There are some steps you can take to increase the accuracy of the results. Firstly, although the profiler supports multiple calls of a profile during each frame, doing this more than a few times can cause the profiler to take significantly longer than the actual code you are trying to profile. Therefore it is recommended that you move the profile up one level (such as outside of a for loop) so that it is called fewer times.

To maximize the accuracy of a profile, it is best to remove the child profiles of the profile you are analyzing. Child profiles increases the frame time of the parent due to the overhead of using the profiler.

Some tests I've conducted show that the profiling code will max out unexpectedly, so take the maximum frame time value with a grain of salt (See the Known Issues section). I think this only happens when a profile is first created, so you can possibly get around this issue by calling the reset() function after the first frame.

Release Version Considerations

For the release version of your app, you should set the macro OGRE_PROFILING to 0 in the OgreConfig.h file. You should also disable the profiler by using setEnabled(false). The profiler is still constructed however, and to completely remove the profiler you should comment out where it's created and deleted in OgreRoot.cpp.

However, if the build you are using has been compiled with the OGRE_PROFILING macro set to 0 and you still want to use the profiler without recompiling your SDK, a quick workaround is to instanciate a dummy profiler like this :

// Create dummy profile to set singleton pointer
new Profiler();

// Give it a timer and enable it (memory leak here)
#if OGRE_VERSION_MAJOR == 1 && OGRE_VERSION_MINOR >= 7 // If you're using a version newer than 1.7.
    Ogre::Timer* profileTimer = new Ogre::Timer(); // Don't forget to delete this later!


The profiler will now work but the 3 OgreProfile macro will not work. You will have to manually use the beginProfile() and endProfile() method. You can also instantiate scope-limited Profile objects or simply define your own macros somewhere in your code.

#define MyOgreProfile( a ) Ogre::Profile _OgreProfileInstance( (a) )
#define MyOgreProfileBegin( a ) Ogre::Profiler::getSingleton().beginProfile( (a) )
#define MyOgreProfileEnd( a ) Ogre::Profiler::getSingleton().endProfile( (a) )

Known Issues

  • Profiles are known to take a significant chunk of frame time for no apparent reason. This may be when the profile is first created.
  • Profiles that are not called in the first frame probably won't be shown in the correct order in the display or in the log, but their hierarchy spacing will still be correct.
  • There is an artificial cap of 50 on the number of profiles you can have at one time. This is so the profiler can create a certain number of display elements on initialization.