Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Prozak

In-Engine Profiling

This topic is 5285 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, im looking for an in-engine profiling solution, something maybe using: - Macro Solutions: maybe with clever use of macros we can implement a profiling solution? - Ability to turn On/Off: Yea, this ability is important to me, and i expect a bit of a slow-down when on... - Zero Overhead when Off: I would like for the profiling system to provide zero overhead when turned off. Im looking for tips from coders that have done something similar, maybe online articles or book pointers would be nice too... Thanks in advance. Salsa cooked it, your eyes eat it!
[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][My DevDiary]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"our stupidity allways comes back to bite us in the ass... in a white-shark sort of way..." - Prozak

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
lol - you''d have to ask this at a time when my main computer is down! (I don''t have access to my source.) I haven''t slept yet so please take any typos/etc into account.

In c++ this is fairly easy.

The objectives were to have any initialization done beforehand, low overhead while running, and a simple one liner to type in for any point I wanted profiled.


I first created a struct to that stored the info I wanted in the profile. These records were kept in an array so I could print it out just before the program terminated. In that record I stored such things as a user defined string name, the number of times that entry was triggered, and naturally the total time for that entry. In the code, each entry was identified by it''s index.

In order to make things easier to maintain, I created a class similar to this:


// Stuff explained below

class MyProfiler
{
public:
static int nesting;
static int NewProfile(const char * name);
MyProfiler(int idx);
~MyProfiler();
}

MyProfiler::nesting=-1;

#define PROFILE(STR) static int ProfileID=MyProfiler::NewProfile(STR); MyProfiler ProfileVar(ProfileID);


The static function simply sets up an index entry for the #define. Since this is static, it is only done once (to obtain the index for the define) and a benefit is that any code executed here is done before your main code is executed.

The constructor does nothing much except to record the current time in the struct and increment a counter (so I could see how many times a piece of code was called). It also stored the previous "nesting" value inside it and then sets "nesting" set to "idx". In this way I could subtract the time of any profiled code that was executed inside the current scope.

ie: Assume routine A calls routine B. Routine A takes 10 seconds but routine B takes 8 seconds. I have found at times it was useful to know that routine A took 10 seconds - but at times I wanted to know that only 2 out of the 10 seconds were in the main code for routine A and the rest was due to other profiled routines called inside it.

The destructor calculated the elapsed time for that record and restored the "nesting" variable from the struct.


The nice part of this code is the macro just has to be placed just once in the scope of the code to be profiled - the destructor is automatically called at the scope end. Another nice feature is that a string is passed in so you can give the profile any meaningful description.

It is also quite fast - since the index to the struct is pre-recorded, the constructor/destructor has immediate access to the record and can quickly tally any results.


sample usage:
main()
{
PROFILE("main")
... some code
for (i=1; 1<1000; i++)
{
PROFILE("Some loop")
... more code
}
... etc
}



Hope this tip helps. It may not be the best solution but it worked for me.

Share this post


Link to post
Share on other sites
Thanks for the replies, at this moment i have my hands filled with other stuff, so.... once that is done, ill be sure to check that code, and yes, i own all the GP Gems books, so ill also have to look into it.

Thanks

Salsa cooked it, your eyes eat it!
[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][My DevDiary]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"our stupidity allways comes back to bite us in the ass... in a white-shark sort of way..." - Prozak

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!