GG staff mentioned... a profiler?
by bentgarney · in Torque Game Builder · 03/13/2005 (5:36 pm) · 11 replies
#2
03/14/2005 (2:07 am)
Um, what's a profiler?
#3
Don't forget about profilerDumpToFile() to get a permenant copy.
Brian: What the name suggests, it's a way to profile (test the speed of) code. T2D is based on TGE, which has a basic but very functional profiler class built in. (And it's multiplatform.)
It's also got a journaling system (logs all system events and allows for reply to recreate bugs) and a decent memory analyzer.
03/14/2005 (2:50 am)
Robert: You'll need to write the T2D functions you are interested in the ProfileGroupStart()/ProfileGroupEnd() functions. But you probably already figured that out. :)Don't forget about profilerDumpToFile() to get a permenant copy.
Brian: What the name suggests, it's a way to profile (test the speed of) code. T2D is based on TGE, which has a basic but very functional profiler class built in. (And it's multiplatform.)
It's also got a journaling system (logs all system events and allows for reply to recreate bugs) and a decent memory analyzer.
#4
03/14/2005 (10:06 am)
Yeah, I've been wondering what the heck the journal calls are that I see in the console reference doc. I thought it might be a RPG journal feature. :) Seriously, though, some docs on these mysterious calls would be wonderful.
#5
You MUST match all STARTS with ENDs -- for all paths your code might take. So, if your method/function bails out early with a return statement, you must have a PROFILE_END() just before it jumps back. If you do not, the profiler will never return a function list. (It'll still have an open declaration.) For example:
03/14/2005 (1:15 pm)
Robert: To profile a section of code, you have to write it with two macros called PROFILE_START(sectionname); and PROFILE_END(); ("sectionname" can be anything, though of course it should reflect what method your profiling. Just be careful, the macro uses it as a sort of hash table variable, so stick to the usual C++-variable naming rules. ie: Don't do something like PROFILE_START(This is my code); as it will generate errors.)You MUST match all STARTS with ENDs -- for all paths your code might take. So, if your method/function bails out early with a return statement, you must have a PROFILE_END() just before it jumps back. If you do not, the profiler will never return a function list. (It'll still have an open declaration.) For example:
void blahclass::blahmethod (void)
{
PROFILE_START (blahmethod);
if (blahvar) {
PROFILE_END();
return ;
}
....
PROFILE_END();
}
#6
Maybe I should say "What does a profiler do for you in the Torque 2d product"?
03/14/2005 (5:43 pm)
LOL ok but what is a "profiler". Remember not everyone is a programmer here.Maybe I should say "What does a profiler do for you in the Torque 2d product"?
#7
If you find certain blocks that are taking up a very large amount of cpu time per tick, then you'll probably want to optimize that code--if you cannot do that, you'll probably want to refactor your design to not run into that type of performance roadblock.
Honestly, it's either for curiosity, or when you are really strapped for performance, and need to squeek out additional cpu cycles. A very large portion of game (and code in general) don't spend too much time profiling if the user is never waiting on the application in the first place.
03/14/2005 (6:24 pm)
It helps you to analyse how much processor time is being spent within a particular PROFILE_START/PROFILE_END block. For example, if your game is running slowly when XXX happens, you can find the code that handles XXX, and set up a profiling block for code that you think may be slow for some reason (huge loops? really funky math formulas? etc.), and then run the game with profiling enabled and confirm your suspicions.If you find certain blocks that are taking up a very large amount of cpu time per tick, then you'll probably want to optimize that code--if you cannot do that, you'll probably want to refactor your design to not run into that type of performance roadblock.
Honestly, it's either for curiosity, or when you are really strapped for performance, and need to squeek out additional cpu cycles. A very large portion of game (and code in general) don't spend too much time profiling if the user is never waiting on the application in the first place.
#8
Maybe I should say "What does a profiler do for you in the Torque 2d product"?
03/14/2005 (6:27 pm)
LOL ok but what is a "profiler". Remember not everyone is a programmer here.Maybe I should say "What does a profiler do for you in the Torque 2d product"?
#9
If you are a programmer working in the code it will tell you how much time is spent in a block of code which is very useful at times.
03/14/2005 (6:43 pm)
If you are not a programmer, and are not modifying the source code, then a profiler will not do much for you.If you are a programmer working in the code it will tell you how much time is spent in a block of code which is very useful at times.
#10
Update: Oh yeah, there's a processor define for enabling those PROFILE_XXX calls. Otherwise, they are just nulled out. I think it's PROFILE_ENABLE or some such. Check the profile.h file to see.
03/14/2005 (7:53 pm)
Plus, if you're not a programmer and don't plan on using it, then don't turn it on or even mess with it. There is a overhead (albeit fairly small) for those PROFILE_XXX calls.Update: Oh yeah, there's a processor define for enabling those PROFILE_XXX calls. Otherwise, they are just nulled out. I think it's PROFILE_ENABLE or some such. Check the profile.h file to see.
#11
In the new "fxUtility2D.h", you'll find an entry...
_".
Here is a list of the ones that are defined so far...
T2D_fxSceneWindow2D_onRender - Window Rendering Time.
T2D_fxSceneContainer2D_findObjects - Time Finding Objects in Container System.
T2D_fxSceneContainer2D_findPotentialCollisions - Time Finding Objects for Potential Collisions (broad-phase).
T2D_fxSceneObject2D_processCollisionStatus - Time Processing Found Collisions.
T2D_fxSceneObject2D_updateWorldLimit - Time Checking/Processing the World-Limits.
T2D_fxSceneObject2D_calculateSpatials - Time Updating spatial information for scene objects.
T2D_fxSceneObject2D_checkCollisionSend - Time Checking for send collisions.
T2D_fxSceneObject2D_calculateMountNodes - Time Calculating Mount-Node Positions.
T2D_fxSceneObject2D_updateMount - Time Mounted Objects take updating their mounted positions.
T2D_fxSceneContainer2D_BinRelocation - Time taken relocating objects in the container system.
T2D_fxSceneContainer2D_allocateSceneBinReference - Time Allocating bins for the container system.
T2D_fxSceneContainer2D_freeSceneBinReference - Time Deallocating bins for the container system.
T2D_fxSceneContainer2D_addSceneReferenceBlock - Time adding Bin-Blocks to the container system.
T2D_fxPhysics2D_collide - Time Checking for Collisions (narrow-phase).
T2D_fxPhysics2D_update - Time updating physics.
T2D_fxPhysics2D_generateCollisionPoly - Time updating collision-polygons.
T2D_fxPhysics2D_findContactPoints - Time calculating contact points.
T2D_fxPhysics2D_resolveOverlap - Time resolving overlaps.
T2D_fxPhysics2D_resolveCollision - Time resolving forward-time collisions.
This is obviously only useful to those who know how to use the profiler in the first place. If you leave the "T2D_DEBUG_PROFILING" commented-out, none of the "PROFILE_START/END" macros will be included, neither will the "profiler.h".
- Melv.
04/14/2005 (12:17 pm)
Just thought I'd add here that in the update there are a number of profiler entries I've added that make things a little easier to track.In the new "fxUtility2D.h", you'll find an entry...
#define T2D_DEBUG_PROFILING // Remove Comments for T2D Debug Profiling.Removing the comments here will build T2D with additional "PROFILE_START/END" entries for most of the major systems. They all have this format "T2D_
Here is a list of the ones that are defined so far...
T2D_fxSceneWindow2D_onRender - Window Rendering Time.
T2D_fxSceneContainer2D_findObjects - Time Finding Objects in Container System.
T2D_fxSceneContainer2D_findPotentialCollisions - Time Finding Objects for Potential Collisions (broad-phase).
T2D_fxSceneObject2D_processCollisionStatus - Time Processing Found Collisions.
T2D_fxSceneObject2D_updateWorldLimit - Time Checking/Processing the World-Limits.
T2D_fxSceneObject2D_calculateSpatials - Time Updating spatial information for scene objects.
T2D_fxSceneObject2D_checkCollisionSend - Time Checking for send collisions.
T2D_fxSceneObject2D_calculateMountNodes - Time Calculating Mount-Node Positions.
T2D_fxSceneObject2D_updateMount - Time Mounted Objects take updating their mounted positions.
T2D_fxSceneContainer2D_BinRelocation - Time taken relocating objects in the container system.
T2D_fxSceneContainer2D_allocateSceneBinReference - Time Allocating bins for the container system.
T2D_fxSceneContainer2D_freeSceneBinReference - Time Deallocating bins for the container system.
T2D_fxSceneContainer2D_addSceneReferenceBlock - Time adding Bin-Blocks to the container system.
T2D_fxPhysics2D_collide - Time Checking for Collisions (narrow-phase).
T2D_fxPhysics2D_update - Time updating physics.
T2D_fxPhysics2D_generateCollisionPoly - Time updating collision-polygons.
T2D_fxPhysics2D_findContactPoints - Time calculating contact points.
T2D_fxPhysics2D_resolveOverlap - Time resolving overlaps.
T2D_fxPhysics2D_resolveCollision - Time resolving forward-time collisions.
This is obviously only useful to those who know how to use the profiler in the first place. If you leave the "T2D_DEBUG_PROFILING" commented-out, none of the "PROFILE_START/END" macros will be included, neither will the "profiler.h".
- Melv.
Torque Owner Josh Williams
Default Studio Name
If you encounter any probs with the profiler, let me know. I only had the opportunity to run real basic tests on it.