Performance Panel

Jump to: navigation, search
Performance Panel.png
The HeroBlade Performance Panel shows how much relative time that several functions on the client are taking per frame. This is mostly of interest to programmers working on the client, but in some cases can be useful to track down performance problems.



The data is organized in a hierarchy, where, for example, "OSRender" is a child of "WinRun", thus WinRun includes all the time taken by OSRender.

Each entry in the tree has four bar graphs:

  1. real-time percentage of total frame time
  2. running average percentage of total frame time
  3. real-time percentage of parent time
  4. running average percentage of parent time

You'll notice that the first and third bars in some cases will vary drastically each frame, indicating rapid fluctuations, where the second and fourth bars are more stable and easier to read.

Things to keep in mind when reading these performance graphs:

1. They indicate a percentage of time, not an absolute time. When a graph rises it may mean that function is taking more time -- or that other functions are taking less time.

2. DirectX and graphics drivers may cache some operations, which get performed together during a later call. This can slightly distort performance data regarding DirectX calls.

3. "T" time (graphs 1 + 2 per entry) is more important than "P" time. A function that takes a very high percentage of a very small amount of time is generally not a problem.

The Entries

These items indicate time spent in the collision system. The collision system is used for character placement, camera behavior, plant emitters, the particle system, and finding world objects under the mouse.
  • If frame rate is low, you might want to check "T" on these in general, but don't worry about the hierarchy or the "P" times. Excessive collidable geometry, CollisionResponse settings on particles other than COLLIDE_IGNORE, and soft grass shadows can overwork the collision system.
DMC: configure 
Dynamic Model Configuration for characters. This should generally take little to no time except when a character with parts (i.e. players, some types of creatures) is being composited.
  • Tip: Do not pack NPCs too densely in an area and this should be fine.
HeroScript Exec 
The amount of time spent running HeroScript code on your client.
  • Keep an eye on this to make sure you're not hurting the framerate with inefficient code.
Thread Logs 
Time spent logging messages from other threads.

Win Run

Time spent by the engine. Expect the "T" percentages to be high, as this is the meat of the client.
D3D Present() 
Amount of time DirectX spends finalizing the rendering of a frame.
  • High percentages here are a sign that your video card settings may be unusual. High anti-aliasing settings on ATI cards for instance may slow your frame rate considerably.

OS Render

The sum total of all CPU time spent organizing and drawing objects.
World Render 
Almost the same as OSRender, and should run about 98-99% "P" time.
Character Render 
Time spent rendering characters (including creatures).
Mesh Render Vertex Deformation and BB Update 
Time spent deforming vertices on characters (the end result of animation).
Amount of time spent rendering GUI elements.
  • High "T" time here indicates a problem if frame rate is low; perhaps just too many GUI elements.
Time spent rendering any control that's not text.
Time spent rendering any control that IS text.
Render Particle List 
Time spent rendering particles.
Time spent rendering world objects once they've been prepared.
Time spent by DirectX in actually running shader code and DrawPrimitive calls.
PostBatch, PostBucket, PreBatch, PreBucket 
Time spent in internal rendering loop callbacks.
Time spent in each lighting pass, including the directional light.
Time spent looping through material buckets -- the majority of RenderByLight code, minus a little overhead for light settings.
Time spent looping through each mesh within a material bucket -- the majority of BucketLoop, minus time for texture changes.
Time spent locking vertex buffers for deformation of animated assets and characters.
Time spent preparing SpeedTrees for RenderSceneRender, and rendering any SpeedTree billboards.
World Render Mirrors 
Will be 0 unless you've got a mirror visible.
  • Tip: very visible mirror causes the world to be rendered an extra time per frame. Use them sparingly and judiciously.

OS Update

Time spent doing anything that ISN'T rendering -- moving objects, processing animation, communication, etc.
Time spent activating/deactivating rooms when the active room changes.
Time spent activating an area during asynchronous area loading.
Camera Collision 
Time spent testing the camera for collision against world objects.
FireStorm Pump 
Time spent sending and receiving data over the network.
GOM Pump 
Time spent updating Game Object Model data.
Select Active Rooms 
Time spent deciding which room should be active, based on character/camera position.
World Update 
Time spent moving in-game objects and processing miscellaneous things.
Audio Update 
Time spent managing DirectX audio.
Char Update 
Time spent updating characters.
  • Large "P" percentages indicate a lot of time is being spent on characters. Unlike other game objects, characters that are capable of movement update even if they're not in a visible room, just in case they happen to walk into one.
AnimMixer Evaluate 
Time spent in the animation system.
DMC: GetMeshes 
Dynamic Model Configuration stuff for characters.
Inventory and Tracer 
Time spent adjusting positions of objects held/worn by characters which are not a part of their model.
Mostly, time spent by local characters preparing and sending movement packets to the server.
Time spent deciding which animations are appropriate to perform, and preparing for animation.
Time spent colliding characters with the ground so they don't hover in the air.
  • When there are a lot of active characters/NPCs and a lot of geometry to collide with, this may be high.
Time spent tracking remotely controlled characters and processing local character control.
Time spent updating movement sensors (which detect collidable objects) for local characters.
Compositing Manager::Update 
Time spent compositing characters.
Time spent setting texture LODs for characters.
Particle Update 
Time spent updating particles and emitters.
  • If this is high and frame rate is low, chances are there's just too much going on with particles.
Particle Collision 
Time spent colliding particles that have CollisionResponse set to anything other than COLLIDE_IGNORE.
  • Tip: Don't use CollisionResponse unless absolutely necessary, and if you must use it, limit the number of particles involved and the complexity of their motion. Particle collision tries to optimize by predicting the collision point, but it can't do it if you're using LinkChildren, Motion, or attractors.
Plant Emitter 
Time spent by PlantEmitters; normally very low unless the camera is moving.
Time spent finding positions for plants (which involves the collision system).
Time spent deleting plants that have fallen out of range.
Time spent deciding which active plant grid squares are visible at the current camera angle.
Time spent managing the queue of plant grid squares. (As the camera moves, not all plant grids are done in a single frame but are spread out to reduce hitching.)
Time spent adding new plant grid squares to the queue.
Time spent updating particles owned by plant emitters -- negligible for emitters with Fast=true.
TriggerNode Update 
Time spent by client-side TriggerNodes testing for NPCs, cameras and players.

Performance Options

There are options for turning performance monitoring on and off, resetting the data collected so far, and saving the data to a file on the local computer. In Windows 7 the log file is saved to "\users\<user name>\appdata\local\heroengine\" this may be and most likely will be different on different operating system.

See also

Personal tools