Performance counter

Dec 10, 2007 at 2:34 AM
Edited Dec 10, 2007 at 2:40 AM
I think it might be a good idea to create a performance counter. Let me elaborate on how it could work.

Performance monitor is a singleton class. Any class that wants to use it simply creates an instance for it.

Anytime you want to monitor performance of something you simply pass it a category (enum), a string (which could be the class type, or any description you wanted), and maybe an enum to tell it to start.
Then when you're done you pass it the same string and tell it to stop.

The monitor keeps the info for that time elapsed.

Sounds pretty simply, and it is. But there is more.

You can output the results of an entire category of the performance monitor, and it could display the string you passed it, the avg time is take, the maximum time, and a percentage of the category it takes up. This way if I want to monitor 4 major systems, the performance monitor would tell me what percentage of 100% that system took up. Using this I could tell how much time rendering takes up versus networking vs AI, etc. Or if I had an entire category for rendering, it could be used to tell us how much time each step of rendering takes up; If I had bloom postprocessing enabled, it could tell me that bloom took up 6% of the rendering time. Or if I used the system on entities, it could tell me how long the terrain took, versus drawing all models. Or if I used it on scenes it could tell me how long a scene took to render, or if I had 3 scenes it could tell me what percentage of 100% SceneB took to render. I think you're getting the point by now.

I'm fairly excited about this idea. I think I will post an issue for it, and I'll start on it after the camera system is a little more refined.
Here is the work item
Dec 10, 2007 at 3:57 AM
First off, this is essentially what profiling tools do for you. The free ones sometimes don't have "categories," but you can get essentially the same information from looking at the percentage of time per method. If SceneManager.Update() took 40% of the time, that's a fairly good indicator of the real per-frame percentage. With most profilers, you can set a hotkey for starting the profiling so it doesn't start collecting data until you're in a game play state. This way, you don't factor in loading time and menu time. VTune in particular gives you an API for specifying categories names for blocks of code, just as you suggest. I'm not saying this is a bad idea, quite the contrary, I just want to make sure its worth coding all this instead of just using a profiler.

For graphics, you'll want to use PIX. It comes with the DirectX SDK. There is no good way to do this in code, since Draw calls happen asynchronously. Timing your DrawIndexedPrimitive calls is essentially worthless, and timing the entire rendering block will only tell you how much time you spend sending data to the graphics card (plus the time waiting for the next vsync if vsync is enabled). You will have no idea how much time is actually spent rendering a frame. Unless you start blocking with GetData() on render targets, of course. But then you have a whole 'nother problem. ;)

Dec 10, 2007 at 5:45 AM
Shaw is right, there are many profiling tools out there which do a lot better job than we are going to be able to do. Pick one of those :)
Dec 10, 2007 at 5:49 AM
I'll look into those and see how easy they'd be to integrate. I do like trying new things as a learning experience, but there is plenty of work to do with this engine, and if I can use an existing tool then we might as well.