Performance Counters in the XNA Framework
The XNA Framework contains a set of predefined performance counters for analyzing the types of load your application has on the XNA Framework. The counters are not extensible.
You can generate performance statistics about your application at run-time. For a step-by-step procedure, see How to: Monitor Performance at Run Time.
The performance counters are useful for understanding the impact of garbage collection and just-in-time compilation on application performance. From these statistics, you can determine where optimizations should occur.
The statistics file lists performance counters with the following columns.
| Column | Description |
|---|---|
| Total | Summation of occurrences |
| Last Datum | The last piece of information |
| N | The number of occurrences |
| Mean | The intermediate between other values |
| Min | The minimum value |
| Max | The maximum value |
XNA Framework Counters
Performance counters fall into the following categories.
Loader Counters
The following counters pertain to the portion of the common language runtime (CLR) that is responsible for resolving and loading components that are referenced by your application, such as assemblies and classes.
| Name | Description |
|---|---|
| Total Program Run Time (ms) | The elapsed time, in milliseconds, from CLR invocation. |
| App Domains Created | The number of application domains created in the application's process. |
| App Domains Unloaded | The number of application domains that have been unloaded during the run time of the application. |
| Assemblies Loaded | The number of assemblies that have been loaded across all application domains for the application. |
| Classes Loaded | The number of classes that have been loaded across all application domains during the run time of the application. |
| Methods Loaded | The total number of methods loaded across all application domains during the run time of the application. |
Generics Counters
The generics counters are loader counters that are specific to the generics feature of the XNA Framework. The CLR uses generics internally. Consequently, you might see values in these counters even if your application does not use generics explicitly.
| Name | Description |
|---|---|
| Closed Types Loaded | The count of unique generic types that have been loaded across all application domains. A closed type is a generic class that has been bound with a specific data type. For example, an instance of |
| Closed Types Loaded per Definition | The maximum number of unique generic types created for a given definition across all application domains. For example, if an application instantiates A large number (several hundred or more) in the Max column can indicate working-set pressure in terms of JIT-compiled code and CLR data structures. |
| Open Types Loaded | The count of open generic types created across all application domains. An open type is a generic class that has been loaded, but has not been bound with a specific data type. Open types are typically created only in reflection scenarios. For example, loading an instance of |
| Closed Methods Loaded | The count of unique generic methods that have been loaded across all application domains. A closed method is a generic method that has been bound with a specific data type. The type that contains the method may or may not be a generic type. For example, an instance of |
| Closed Methods Loaded per Definition | The maximum number of unique generic methods created for a given definition across all application domains. This counter is similar to the Closed Types Loaded per Definition counter. Using the following instances of |
| Open Methods Loaded | The count of open generic methods created across all application domains. Open methods are typically created only in reflection scenarios. An open method is a generic method that has been loaded, but not bound to a specific type. The XNA Framework runtime uses reflection internally and can be the source of the open methods. |
Locks and Threads Counters
The following counters pertain to threading, locks, timers, and thread pools. These counters can help identify threading-related performance issues by providing data on thread, timer, and lock usage during the run time of your application.
| Name | Description |
|---|---|
| Threads in Thread Pool | The number of threads currently in the thread pool. This counter counts the threads that are started by using the System.Threading.ThreadPool.QueueUserWorkItem method. This counter does not include threads that are started by using the System.Threading.Thread.Start method. |
| Pending Timers | The number of timers currently queued. |
| Scheduled Timers | The number of timers that are currently running or scheduled to run. |
| Timers Delayed by Thread Pool Limit | The number of timers that have been delayed by the thread pool limit. |
| Work Items Queued | The number of work items queued to the thread pool. |
| Uncontested Monitor.Enter Calls | Number of calls made to the System.Threading.Monitor.Enter method that were not contested. |
| Contested Monitor.Enter Calls | Number of calls made to Monitor.Enter that were contested. In multi-threaded applications, if Thread1 is holding a lock and Thread2 needs to access code that is guarded by the lock, the Contested Monitor.Enter Calls counter is incremented. |
Garbage Collection Counters
The following counters pertain to garbage collection operations.
| Name | Description |
|---|---|
| Peak Bytes Allocated (native + managed) | The maximum number of bytes in use by the CLR, including both native and managed memory. |
| Managed Objects Allocated | The count of objects allocated by the garbage collector. |
| Unused Managed Objects Allocated | The count of objects allocated that were never used. |
| Managed Bytes Allocated | The count of bytes allocated by the garbage collector. |
| Unused Managed Bytes Allocated | The count of bytes allocated that were never used. |
| Managed String Objects Allocated | The number of managed string objects allocated by the garbage collector. |
| Bytes of String Objects Allocated | The count of bytes of string objects allocated by the garbage collector. |
| Garbage Collections (GC) | The number of times the garbage collector has run. |
| Bytes Collected by GC | The count of bytes collected by the garbage collector. |
| Managed Bytes in Use After GC | The number of bytes allocated to live objects after the last garbage collection. |
| Total Bytes in Use After GC | The number of bytes of memory, native and managed, in use after the last garbage collection. |
| GC Compactions | The number of times the garbage collector has compacted the heap. |
| Code Pitchings | The number of times the garbage collector has discarded JIT-compiled code. |
| Calls to GC.Collect | The number of times the application has called the System.GC.Collect method. |
| GC Latency Time (ms) | The total time, in milliseconds, that the garbage collector has taken to collect objects and compact the heap. The latency time of the garbage collector includes the time to collect managed objects that are no longer in scope and the compaction time, if necessary, of the GC Heap. |
| Pinned Objects | The count of pinned objects encountered while performing a garbage collection. Pinned objects are objects whose locations in memory cannot change. For example, a memory buffer that is being used to communicate between managed and unmanaged code is a pinned object. Pinned objects cannot be moved by the garbage collector during heap compaction. |
| Objects Moved by Compactor | The count of objects moved by the garbage collector during a compaction. |
| Objects Not Moved by Compactor | The count of the objects that were not moved by the garbage collector during a compaction. Objects might not be moved for a number of reasons. Some objects cannot be moved, but these objects are rare. Other objects are not moved because they are in a portion of the heap that does not need to be compacted. |
| Objects Finalized | The count of objects for which a finalizer has been run. |
| Boxed Value Types | The number of value types that have been boxed. |
JIT Counters
The following counters pertain to JIT compiler operations.
| Name | Description |
|---|---|
| Native Bytes Jitted | The count of bytes of native code generated by the JIT compiler. |
| Methods Jitted | The count of methods generated by the JIT compiler. |
| Bytes Pitched | The count of bytes of native code generated by the JIT compiler that has been discarded. |
| Methods Pitched | The count of methods generated by the JIT compiler that have been discarded. Unless your application was moved to the background during its run time, any positive value for the Methods Pitched counter indicates that the application ran under memory pressure. |
| Method Pitch Latency Time (ms) | The total time, in milliseconds, spent discarding methods generated by the JIT compiler. |
Exceptions Counters
The following counters pertain to exceptions.
| Name | Description |
|---|---|
| Exceptions Thrown | The count of managed exceptions that have been thrown. Because throwing an exception consumes significant resources, tracking the number of exceptions thrown by your application can help identify potential design issues. |
See Also
Concepts
How to: Monitor Performance at Run Time
Garbage Collection
Automatic Memory Management
Reference
System.Threading.Thread Class
System.Threading.ThreadPool.QueueUserWorkItem Method
System.Threading.Thread.Start Method
System.Threading.Monitor.Enter Method
System.GC.Collect Method