David Kline : Performance

.NET Compact Framework v3.5 Power Toys CTP

DavidKlineMS — Thu, 13 Sep 2007 20:59:52 GMT

The .NET Compact Framework team made an exciting CTP available this week. The .NET Compact Framework v3.5 Power Toys September 2007 CTP release contains some old friends (ex: Remote Performance Monitor) and ads some great new ones (Service Model Metadata Tool, App Configuration Tool, etc).

Here's what the download page has to say about the included tools:

Remote Performance Monitor and GC Heap Viewer – Provides real time counter data (ranging from Garbage Collector activity to type loading info) on a running NETCF application. The GC Heap Viewer feature allows you to capture the managed heap at any moment your app is running to view live references, and allows you to compare multiple snapshots to find memory leak issues.

NETCF CLR Profiler – CLR Profiler is an instrumenting allocation profiler for NETCF applications. It provides detailed allocation visualizations, allocation callstacks visualizations and useful for diagnosing memory management issues.

App Configuration Tool (NetCFcfg.exe) - On-device tool for specifying what version of the NETCF runtime an application will run against, displaying installed versions of NETCF and displaying info about DLLs in the GAC.

NETCF ServiceModel Metadata Tool – The .NET Compact Framework ServiceModel Metadata Tool (netcfsvcutil.exe) allows you to generate a Windows Communication Foundation (WCF) client proxy to help developers consume WCF services on device. Like svcutil.exe, which is the desktop version of the utility, netcfsvcutil.exe is a command-line tool that generates service model code from metadata documents and generates metadata documents from service model code.

Remote Logging Configuration Tool – The Logging Configuration Tool enables users to easily configure logging options on a NETCF device including: loader, interop, network, error and finalizer logs.

NETCF Network Log Viewer – A utility for viewing NETCF network log data.

Dan Horbatt and Andrew Arnott talk in detail about the new Service Model Metadata Tool here (Dan) and here (Andrew).

I highly recommend downloading and using the power toys. And as always, please send us your feedback.

Enjoy!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

Testing performance

DavidKlineMS — Fri, 08 Jun 2007 22:41:43 GMT

A couple of weeks ago, I described the test development priorities for the .NET Compact Framework team. As part of that discussion, I stated that performance should be tested in parallel with the other forms of testing (unit, customer scenarios, etc). Today, I would like to spend some time talking about performance testing.

General considerations
When testing performance, there are a few key things to keep in mind.

First, it is important to measure the intended scenario. In the past, I have seen a number of tests that were intended to time a data processing operation (ex: sort algorithm) that inadvertently included the time to load the data from the file system.  As a result, the performance data being reported was quite inaccurate.

Second, since today's operating systems are multi-tasking, it is recommended to test performance on as clean of a system (fewest running processes) as possible and to run the performance test multiple times to ensure accurate data. Depending on the scenario being timed, the jitter (variance in results) can be significant and important to take into account when reporting results. I will talk a bit more about performance reporting shortly.

Lastly, I have found that most meaningful performance measurements for applications I have written are when the application is in sustained operation. What I mean by this is that any Just-In-Time compilation has already occurred and I am measuring the typical run time performance of my scenario. Most often, code is Just-In-Time compiled once per instance of the application, so the performance impact is felt only the first time the method is called. There are some exceptions to this rule of thumb, and I have found that in those cases, even when pre-JIT compiling the scenario, the results are reasonably accurate. What are these exceptions? Memory pressure and moving the application to the background. In each of these cases, the .NET Compact Framework's Garbage Collector will run and may discard JIT compiled code and be forced to recompile when the situation is resolved (memory has been freed, the application is brought to the foreground). In both of these cases, the timing loop will reflect the time spent freeing memory and re-JIT compiling.

Macro-benchmarks
Macro-benchmarks are performance tests for long duration scenarios. By "long", I mean that the scenario takes a second or more to complete. When testing macro-benchmarks, I typically run the scenario a handful (10-50) times in a loop. Because the scenario takes a significant amount of time to run, the time spent looping does not significantly impact the measurements. When the timing loop is complete, dividing the time spent (number of elapsed ticks) by the number of loop iterations results in the scenario's performance measurement, as shown in the following example.
// run the scenario once (to avoid timing the initial Just-In-Time compile) Scenario(data); // timing loop Int32 iterations = 10; Int32 start_ms = Environment.TickCount; for(Int32 i = 0; i < iterations; i++) {     Scenario(data); } Int32 finish_ms = Environment.TickCount; // calculate the performance Double average_ms= (Double)(finish_ms - start_ms) / (Double)(iterations);
Macro-benchmarks are often based on customer scenarios and improving their performance can often lead to significant gains in customer satisfaction. At times, making improvements to macro-benchmarks requires changes to the scenario implementation. To address this, I highly recommend measuring your scenarios as early as possible in the development of the product. That way, if the performance does not meet the requirements, there is time to write and test the new implementation.

Micro-benchmarks
Micro-benchmarks are performance tests on the small scale, measuring very short duration operations. To get an accurate measurement, performance tests need to run the scenario a large number of times (I typically run my micro-benchmark scenarios 10,000 or more times). Also, it is important to keep in mind that, unlike macro-benchmarks, the time spent looping can significantly impact the performance measurements. To minimize these impacts, I recommend what I call "playing optimizing compiler" and partially unrolling your timing loop. The example below updates the macro-benchmark example for micro-benchmark testing.
// run the scenario once (to avoid timing the initial Just-In-Time compile) Scenario(data); Int32 iterations = 1000; Int32 callsInLoop = 10; // timing loop Int32 start_ms = Environment.TickCount; for(Int32 i = 0; i < iterations; i++) {     Scenario(data);     Scenario(data);     Scenario(data);     Scenario(data);     Scenario(data);     Scenario(data);     Scenario(data);     Scenario(data);     Scenario(data);     Scenario(data); } Int32 finish_ms = Environment.TickCount; // calculate the performance Double average_ms= (Double)(finish_ms - start_ms) / (Double)(iterations * callsInLoop);
Since the scenario is very short, this test runs the code 10,000 times and partially unrolls the loop (1,000 iterations of 10 calls). This significantly minimizes the impact of the time spent looping. In one example scenario I tested, the time spent when in a tight loop (10,000 iterations of 1 call), was reported as 1 millisecond. When using the timing loop shown above, that time was reduced to 0.95 milliseconds - 5% faster than previously reported. With additional loop unrolling (ex: 500 iterations of 20 calls) we can further improve the accuracy of the measurement. Of course, there is a point of diminishing returns when continued unrolling becomes unrealistic and the improved measurement accuracy is no longer significant.

Reporting performance results
I mentioned results reporting earlier. When I report performance results, I use one of two methods: raw speed reporting and what I call "gymnastics" reporting.

In raw speed reporting, I run my performance test multiple times (the exact number depending on whether or not I am timing a micro- or macro-benchmark) and keeping only the fastest result. This approach helps to factor out the sometimes subtle differences in results when running on multi-tasking operating systems (ex: the scheduler runs a background task) and is closer to the maximum throughput of the code.

In "gymnastics" reporting, I again run my performance test multiple times, but this time, I discard the extreme results (fastest and slowest) and average the remaining data. The resulting data is closer to the typical performance that the customer will see during everyday use of the product.

Take care!
-- DK

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.

Using the .NET Compact Framework Remote Performance Monitor to Configure Diagnostic Options

DavidKlineMS — Thu, 31 Aug 2006 23:26:00 GMT

Diagnostic, performance and debugging tools are very cool. The more tools available, the easier it tends to be to find and fix application issues. With Visual Studio 2005, several handy tools were added. I use the Remote Registry Editor and Remote File Viewer just about every day. Version 2 of the .NET Compact Framework added diagnostic logs (enabled via the device registry) to help identify application problems in places where it was very difficult, or not possible to find them with other tools.

One difficulty with using the diagnostic logs is setting the registry options. Modifying the registry can be intimidating and, if done incorrectly, a risky proposition. Readers familiar with my writings on using the diagnostic logs will recall that every time I mention the Remote Registry Editor, I include a warning to use the tool with great care.

A few months ago, Steven posted a tour of the .NET Compact Framework Remote Performance Monitor. He talked about installation, getting connected, publishing the statistics to the Windows Performance Monitor and touched upon what I am going to talk about today.

Did you know that you can use the .NET Compact Framework Remote Performance Monitor to configure diagnostic options on a device?

The other day, I was writing about using the MDbg command line debugger to attach to a .NET Compact Framework application and I needed to enable attach to process support. On my way to the Start menu to run the Remote Registry Editor, I noticed that I had the .NET Compact Framework Remote Performance Monitor running and remembered that it could configure the device registry for me. Having had the experience of incorrectly modifying this very registry flag while presenting at MEDC, I decided to save myself the embarrassment of making the same mistake again.

On the Device menu of the .NET Compact Framework Remote Performance Monitor, select Logging Options.

The first step that is required is to connect to your device. The steps to connect here are the same as those Steven describes to connect to the performance statistics. Once connected, you can configure your desired diagnostic settings.

Once connected, you can

Enable the Loader, Native Interop and Network logs
Configure log file naming options
Enable performance statistics (.stat) file creation
Enable attach to process support in the debugger

Enjoy!
-- DK

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.

Application Performance: Value Type Boxing

DavidKlineMS — Sat, 27 May 2006 01:59:00 GMT

One of the most popular .NET Compact Framework demos at MEDC 2006 was the .NET Compact Framework Remote Performance Monitor. While working at our booth on the expo floor, I used the .NET Compact Framework Performance Monitor to examine the performance of a simple application that I wrote on the booth PC.

If you had the opportunity to attend Ryan Chapman's MEDC session on optimizing for performance, much of what I talk about today will be very familiar.

The application that I wrote was intentionally ill-performing -- it created a strongly typed collection of integers and copied the collection's data into a collection that was not strongly typed (ex: ArrayList) in a tight loop. Because integers are value types, I knew that boxing would be an issue with this application. What I didn't realize is just how much of an issue boxing could prove to be.

Please note: What follows is a very contrived example intended to show a "worst case" scenario related to the boxing of value types. When designing your application, it is very important to measure performance of algorithms early and often. If your algorithm meets your performance goals, there is no need to dwell on worst case micro-benchmarks.

Example of extreme boxing
The snippet below is based on the example I demonstrated in our booth at MEDC.

List<Int32> numberList = new List<Int32>();
for(Int32 i = 0; i < 13; i++)
{
    numberList.Add(i);
}

ArrayList listCopy = new ArrayList();
for(Int32 i = 0; i < 100000; i++)
{
    // make a copy of the collection
    foreach(Int32 num in numberList)
    {
        listCopy.Add(num);
    }

    // we no longer need the list contents
    listCopy.Clear();
}

Diagnosing the performance of the application
Before the release of the .NET Compact Framework version 2 service pack 1 beta, the implications of excessive boxing can be seen by enabling performance counters and examining the data in the .stat file. Let's take a look at some of the interesting data.

counter	total	last datum	n	mean	min	max
Total Program Run Time (ms)	19476	0	0	0	0	0
Boxed Value Types	1300000	-	-	-	-	-
Garbage Collections (GC)	14	-	-	-	-	-
Bytes Collected By GC	15508684	1112444	14	1107763	1046912	1112444
GC Latency Time (ms)	300	19	14	21	19	25
GC Heap	-	0	34	557056	0	1114112

This example generated boxed 1,300,000 times and the Garbage Collector ran 14 times in under 20 seconds! That is an incredible rate of collection. From the GC latency time, we can see that the Garbage Collector was running very efficiently since there were not many live objects at the time of the collections.

Please notice that even though we collected a large amount of data (15,508,684 bytes) during the runtime of the application, the device was not put under heavy memory pressure -- the GC Heap stayed below 1 MB for the duration of the application.

Removing the boxing
If we modify the example to replace the ArrayList with a second List<Int32> and re-run the test, we see the following data.

counter	total	last datum	n	mean	min	max
Total Program Run Time (ms)	9408	0	0	0	0	0
Boxed Value Types	0	-	-	-	-	-
Garbage Collections (GC)	0	-	-	-	-	-
Bytes Collected By GC	0	0	0	0	0	0
GC Latency Time (ms)	0	0	0	0	0	0
GC Heap	-	0	2	32768	0	65536

As we can see from this set of data, the second version took less than half of the time to run as did the first -- all boxing has been eliminated and no garbage collections occurred. We also used considerably less memory (only 64k) since no objects needed to be constructed.

If you use the .NET Compact Framework Remote Performance Monitor, the data above becomes very easy to see in real time.

During the MEDC booth demo, I ran these examples in tight loops within a worker thread. After 20-30 minutes, the counter for Bytes Collected By GC pegged (got to Int32.MaxValue). We were still collecting, but the counters could no longer track how much data we collected yet the GC Heap size never exceeded 1114112 bytes. The application was doing a huge number of collections, yet was still memory "friendly" on the device.

Please be sure to remember that this is an extreme micro-benchmark example. Value type boxing can be useful in moderation, and does not necessarily cause dramatic application performance issues by itself. It is important to measure application / algorithm performance early and often.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
Some of the information contained within this post may be in relation to beta software. Any and all details are subject to change.

Using .stat Files with the .NET Compact Framework Remote Performance Monitor

DavidKlineMS — Thu, 25 May 2006 10:02:00 GMT

Steven Pratschner recently posted about one of the coolest new features of the Service Pack 1 beta for .NET Compact Framework version 2 -- the .NET Compact Framework Remote Performance Monitor.

Along with the real-time view of the .NET Compact Framework performance statistics, the Remote Performance Monitor can also load and display counter data from .stat files.

To use the .NET Compact Framework Remote Performance Monitor to view .stat files you will need to do the following steps.

Enable performance counters in the device's registry
Run and exit your application (this creates the .stat file)
Copy the .stat file to your PC
Run the .NET Compact Framework Remote Performance Monitor (NetCFRPM.exe)
Load the .stat file from the Open .stat on the File menu

Once the file is opened, the .NET Compact Framework Remote Performance Monitor displays the counter data and a brief description of the each counter. Detailed descriptions of the counters can be found here. The image below shows the data from one of my demo applications from MEDC 2006.

Enjoy!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
Some of the information contained within this post may be in relation to beta software. Any and all details are subject to change.

Wrapping Unmanaged Resources

DavidKlineMS — Tue, 10 Jan 2006 22:48:00 GMT

I recently wrote about three common causes of memory leaks in managed applications. In that post, I mentioned that failing to release unmanaged resources was one cause. Today, I'd like to talk a bit about one approach to working with unmanaged resources that has worked well in my code.

Wrapping Unmanaged Resources
While at MEDC 2005, I showed a simple example of wrapping a DeviceContext (a.k.a. DC) as part of my Debugging .NET Compact Framework Applications session. Here, I would like to expand upon that example. In the snippet below, I show finalization and disposal. I will leave it to the reader to add P/Invoke signatures.

//--------------------------------------------------------------------- //THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY //KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE //IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A //PARTICULAR PURPOSE. //--------------------------------------------------------------------- using System; using System.Diagnostics; using System.Runtime.InteropServices; namespace Snippet { /// <summary> /// Wrapper for the Win32 Device Context (DC) /// </summary> public class DeviceContext : IDisposable { // the Win32 Device Context (DC) object private IntPtr hDC; // window handle associated with the DC private IntPtr hWnd; /// <summary> /// Constructor. /// </summary> /// <param name="hwnd"> /// The window handle for which to retrieve the device context /// </param> public DeviceContext(IntPtr hwnd) { // call the p/invoke to get the device context for the specified window handle IntPtr hdc = GetDC(hwnd); // verify that the GetDC call succeeded if(hdc == IntPtr.Zero) { throw new Exception("Failed to get the DeviceContext for the specified window handle"); } // store the window handle and device context for future reference this.hWnd = hwnd; this.hDC = hdc; } /// <summary> /// Finalizer /// </summary> ~DeviceContext() { // dispose the object (unmanaged resources) this.Dispose(false); } /// <summary> /// Cleanup the object (implementation if IDisposable::Dispose) /// </summary> public void Dispose() { // clean up our resources (managed and unmanaged resources) this.Dispose(true); // suppress finalization // the finalizer also calls our cleanup code // cleanup need only occur once GC.SuppressFinalize(this); } /// <summary> /// Cleanup resources used by the object /// </summary> /// <param name="disposing"> /// Are we fully disposing the object? /// True will release all managed resources, unmanaged resources are always released /// </param> protected virtual void Dispose(Boolean disposing) { if(disposing) { //*** release any managed resources } // release unmanaged resources if(this.hDC == IntPtr.Zero) { // we're already been disposed, nothing left to do return; } Int32 ret = ReleaseDC(this.hWnd, this.hDC); this.hDC = IntPtr.Zero; this.hWnd = IntPtr.Zero; // assert if the DC was not released. Debug.Assert(ret != 0, "Failed to release DeviceContext."); } //*** add desired p/invoke definitions } }

With the resource wrapped, your application can easily interoperate with the native resource.

// get the device context for the primary display DeviceContext dc = new DeviceContext(IntPtr.Zero); //*** perform desired operations on the device context // cleanup dc.Dispose();
The above snippet uses a Debug.Assert to provide notification of a failure when releasing the unmanaged resource:

// assert if the DC was not released. Debug.Assert(ret != 0, "Failed to release DeviceContext.");
By running the debug build during development, you can identify scenarios where cleanup fails and take steps to address the issue before the product ships to your customers.

For additional information regarding finalization and disposal, I recommend reading Implementing Finalize and Dispose to Clean Up Unmanaged Resources, on MSDN.

Enjoy!
-- DK

[Edit: Fixed assert]

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Monitoring Application Performance on the .NET Compact Framework - Table of Contents and Index

DavidKlineMS — Fri, 09 Dec 2005 22:30:00 GMT

When a post series gets as long as Monitoring Application Performance on the .NET Compact Framework (nine parts), it can be difficult to find exactly the portion you need. To help solve this problem, I've created this table of contents as an addendum to the series.

Monitoring Application Performance on the .NET Compact Framework table of contents

Monitoring Application Performance on the .NET Compact Framework Part I - Enabling performance counters

Monitoring Application Performance on the .NET Compact Framework Part II - Version 1 performance counters

Monitoring Application Performance on the .NET Compact Framework Part III - Version 2 performance counters (Part I: Loader counters)

Monitoring Application Performance on the .NET Compact Framework Part IV - Version 2 performance counters (Part II: Generics counters)

Monitoring Application Performance on the .NET Compact Framework Part V - Version 2 performance counters (Part III: Locks and Threads counters)

Monitoring Application Performance on the .NET Compact Framework Part VI - Version 2 performance counters (Part IV: Garbage Collector counters)

Monitoring Application Performance on the .NET Compact Framework Part VII - Version 2 performance counters (Part V: JIT Compiler counters)

Monitoring Application Performance on the .NET Compact Framework Part VIII - Version 2 performance counters (Part VI: Exceptions, Interop and Networking counters)

Monitoring Application Performance on the .NET Compact Framework Part IX - Version 2 performance counters (Part VII: Windows.Forms counters)

Sometimes an index is more useful than a table of contents. The following tables list the performance counters available in the .NET Compact Framework (versions 1 and 2) and a link to the post in which each is discussed.

.NET Compact Framework version 1 performance counter index

Counter	Part
Execution Engine Startup Time	2
Total Program Run Time	2
Peak Bytes Allocated	2
Number Of Objects Allocated	2
Bytes Allocated	2
Number Of Simple Collections	2
Bytes Collected By Simple Collection	2
Bytes In Use After Simple Collection	2
Time In Simple Collect	2
Number Of Compact Collections	2
Bytes Collected By Compact Collection	2
Bytes In Use After Compact Collection	2
Time In Compact Collection	2
Number Of Full Collections	2
Bytes Collected By Full Collection	2
Bytes In Use After Full Collection	2
Time In Full Collection	2
Number Of Application Induced Collections	2
Total Bytes In Use After Collection	2
Bytes Jitted	2
Native Bytes Jitted	2
Number Of Methods Jitted	2
Bytes Pitched	2
Number Of Methods Pitched	2
Number Of Exceptions	2
Number Of Calls	2
Number Of Virtual Calls	2
Number Of Virtual Call Cache Hits	2
Number Of PInvoke Calls	2

.NET Compact Framework version 2 performance counter index

Counter	Part
Total Program Run Time (ms)	3
App Domains Created	3
App Domains Unloaded	3
Assemblies Loaded	3
Classes Loaded	3
Methods Loaded	3
Closed Types Loaded	4
Closed Types Loaded	4
Closed Types Loaded per Definition	4
Open Types Loaded	4
Closed Methods Loaded	4
Closed Methods Loaded per Definition	4
Open Methods Loaded	4
Closed Types Loaded per Definition	4
Open Types Loaded	4
Closed Methods Loaded	4
Closed Methods Loaded per Definition	4
Open Methods Loaded	4
Threads in Thread Pool	5
Pending Timers	5
Scheduled Timers	5
Timers Delayed by Thread Pool Limit	5
Work Items Queued	5
Uncontested Monitor.Enter Calls	5
Contested Monitor.Enter Calls	5
Peak Bytes Allocated (native + managed)	6
Managed Objects Allocated	6
Managed Bytes Allocated	6
Managed String Objects Allocated	6
Bytes of String Objects Allocated	6
Garbage Collections (GC)	6
Bytes Collected By GC	6
Managed Bytes In Use After GC	6
Total Bytes In Use After GC	6
GC Compactions	6
Code Pitchings	6
Calls to GC.Collect	6
GC Latency Time (ms)	6
Pinned Objects	6
Objects Moved by Compactor	6
Objects Not Moved by Compactor	6
Objects Finalized	6
Boxed Value Types	6
Process Heap	6
Short Term Heap	6
JIT Heap	6
App Domain Heap	6
GC Heap	6
Native Bytes Jitted	7
Methods Jitted	7
Bytes Pitched	7
Methods Pitched	7
Method Pitch Latency Time (ms)	7
Exceptions Thrown	8
Platform Invoke Calls	8
COM Calls Using a vtable	8
COM Calls Using IDispatch	8
Complex Marshaling	8
Runtime Callable Wrappers	8
Socket Bytes Sent	8
Socket Bytes Received	8
Controls Created	9
Brushes Created	9
Pens Created	9
Bitmaps Created	9
Regions Created	9
Fonts Created	9
Graphics Created (FromImage)	9
Graphics Created (CreateGraphics)	9

I (and possibly others on the .NET Compact Framework team) plan to link to this post whenever I discuss performance tuning of applications.

Enjoy!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Monitoring Application Performance on the .NET Compact Framework Part IX - Version 2 performance counters (Part VII: Windows.Forms counters)

DavidKlineMS — Fri, 09 Dec 2005 22:23:00 GMT

Loader
	Total Program Run Time (ms)
	App Domains Created
	App Domains Unloaded
	Assemblies Loaded
	Classes Loaded
	Methods Loaded
Generics
	Closed Types Loaded
	Closed Types Loaded per Definition
	Open Types Loaded
	Closed Methods Loaded
	Closed Methods Loaded per Definition
	Open Methods Loaded
Locks and Threads
	Threads in Thread Pool
	Pending Timers
	Scheduled Timers
	Timers Delayed by Thread Pool Limit
	Work Items Queued
	Uncontested Monitor.Enter Calls
	Contested Monitor.Enter Calls
Garbage Collector
	Peak Bytes Allocated (native + manged)
	Managed Objects Allocated
	Managed Bytes Allocated
	Managed String Objects Allocated
	Bytes of String Objects Allocated
	Garbage Collections (GC)
	Bytes Collected By GC
	Managed Bytes In Use After GC
	Total Bytes In Use After GC
	GC Compactions
	Code Pitchings
	Calls to GC.Collect
	GC Latency Time (ms)
	Pinned Objects
	Objects Moved by Compactor
	Objects Not Moved by Compactor
	Objects Finalized
	Boxed Vlue Types
	Process Heap
	Short Term Heap
	JIT Heap
	App Domain Heap
	GC Heap
JIT Compiler
	Native Bytes Jitted
	Methods Jitted
	Bytes Pitched
	Methods Pitched
	Method Pitch Latency Time (ms)
Exceptions
	Exceptions Thrown
Interop
	Platform Invoke Calls
	COM Calls Using a vtable
	COM Calls Using IDispatch
	Complex Marshaling
	Runtime Callable Wrappers
Networking
	Socket Bytes Sent
	Socket Bytes Received
Windows.Forms
	Controls Created
	Brushes Created
	Pens Created
	Bitmaps Created
	Regions Created
	Fonts Created
	Graphics Created (FromImage)
	Graphics Created (CreateGraphics)

counter	total	last datum	n	mean	min	max
Total Program Run Time (ms)	2956837	-	-	-	-	-
App Domains Created	1	-	-	-	-	-
App Domains Unloaded	1	-	-	-	-	-
Assemblies Loaded	8	-	-	-	-	-
Classes Loaded	975	-	-	-	-	-
Methods Loaded	3015	-	-	-	-	-
Closed Types Loaded	75	-	-	-	-	-
Closed Types Loaded per Definition	75	3	22	3	1	10
Open Types Loaded	13	-	-	-	-	-
Closed Methods Loaded	3	-	-	-	-	-
Closed Methods Loaded per Definition	3	1	3	1	1	1
Open Methods Loaded	0	-	-	-	-	-
Threads in Thread Pool	-	0	2	0	0	1
Pending Timers	-	0	4	0	0	1
Scheduled Timers	2	-	-	-	-	-
Timers Delayed by Thread Pool Limit	0	-	-	-	-	-
Work Items Queued	2	-	-	-	-	-
Uncontested Monitor.Enter Calls	664	-	-	-	-	-
Contested Monitor.Enter Calls	0	-	-	-	-	-
Peak Bytes Allocated (native + managed)	2789048	-	-	-	-	-
Managed Objects Allocated	25883	-	-	-	-	-
Managed Bytes Allocated	1366120	24	25883	52	8	135796
Managed String Objects Allocated	5360	-	-	-	-	-
Bytes of String Objects Allocated	124412	-	-	-	-	-
Garbage Collections (GC)	1	-	-	-	-	-
Bytes Collected By GC	897140	897140	1	897140	897140	897140
Managed Bytes In Use After GC	-	147292	1	147292	147292	147292
Total Bytes In Use After GC	-	2621848	1	2621848	2621848	2621848
GC Compactions	0	-	-	-	-	-
Code Pitchings	0	-	-	-	-	-
Calls to GC.Collect	0	-	-	-	-	-
GC Latency Time (ms)	46	46	1	46	46	46
Pinned Objects	0	-	-	-	-	-
Objects Moved by Compactor	0	-	-	-	-	-
Objects Not Moved by Compactor	0	-	-	-	-	-
Objects Finalized	82	-	-	-	-	-
Boxed Value Types	3273	-	-	-	-	-
Process Heap	-	1280	7484	198308	72	330016
Short Term Heap	-	0	6382	963	0	42136
JIT Heap	-	0	6402	421097	0	876976
App Domain Heap	-	0	18679	324926	0	523240
GC Heap	-	0	30	527974	0	1060864
Native Bytes Jitted	844928	208	1963	430	84	9684
Methods Jitted	1963	-	-	-	-	-
Bytes Pitched	0	0	0	0	0	0
Methods Pitched	0	-	-	-	-	-
Method Pitch Latency Time (ms)	0	0	0	0	0	0
Exceptions Thrown	4	-	-	-	-	-
Platform Invoke Calls	0	-	-	-	-	-
COM Calls Using a vtable	0	-	-	-	-	-
COM Calls Using IDispatch	0	-	-	-	-	-
Complex Marshaling	367	-	-	-	-	-
Runtime Callable Wrappers	0	-	-	-	-	-
Socket Bytes Sent	0	-	-	-	-	-
Socket Bytes Received	0	-	-	-	-	-
Controls Created	13	-	-	-	-	-
Brushes Created	23	-	-	-	-	-
Pens Created	8	-	-	-	-	-
Bitmaps Created	16	-	-	-	-	-
Regions Created	0	-	-	-	-	-
Fonts Created	7	-	-	-	-	-
Graphics Created (FromImage)	0	-	-	-	-	-
Graphics Created (CreateGraphics)	0	-	-	-	-	-

That's all of the counters! Thanks to everyone who stuck with this series. It was a long road and will (I hope) provide the basis for some interesting future discussions.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Monitoring Application Performance on the .NET Compact Framework Part VIII - Version 2 performance counters (Part VI: Exceptions, Interop and Networking counters)

DavidKlineMS — Fri, 09 Dec 2005 22:16:00 GMT

Loader
	Total Program Run Time (ms)
	App Domains Created
	App Domains Unloaded
	Assemblies Loaded
	Classes Loaded
	Methods Loaded
Generics
	Closed Types Loaded
	Closed Types Loaded per Definition
	Open Types Loaded
	Closed Methods Loaded
	Closed Methods Loaded per Definition
	Open Methods Loaded
Locks and Threads
	Threads in Thread Pool
	Pending Timers
	Scheduled Timers
	Timers Delayed by Thread Pool Limit
	Work Items Queued
	Uncontested Monitor.Enter Calls
	Contested Monitor.Enter Calls
Garbage Collector
	Peak Bytes Allocated (native + manged)
	Managed Objects Allocated
	Managed Bytes Allocated
	Managed String Objects Allocated
	Bytes of String Objects Allocated
	Garbage Collections (GC)
	Bytes Collected By GC
	Managed Bytes In Use After GC
	Total Bytes In Use After GC
	GC Compactions
	Code Pitchings
	Calls to GC.Collect
	GC Latency Time (ms)
	Pinned Objects
	Objects Moved by Compactor
	Objects Not Moved by Compactor
	Objects Finalized
	Boxed Vlue Types
	Process Heap
	Short Term Heap
	JIT Heap
	App Domain Heap
	GC Heap
JIT Compiler
	Native Bytes Jitted
	Methods Jitted
	Bytes Pitched
	Methods Pitched
	Method Pitch Latency Time (ms)
Exceptions
	Exceptions Thrown
Interop
	Platform Invoke Calls
	COM Calls Using a vtable
	COM Calls Using IDispatch
	Complex Marshaling
	Runtime Callable Wrappers
Networking
	Socket Bytes Sent
	Socket Bytes Received
Windows.Forms
	Controls Created
	Brushes Created
	Pens Created
	Bitmaps Created
	Regions Created
	Fonts Created
	Graphics Created (FromImage)
	Graphics Created (CreateGraphics)

counter	total	last datum	n	mean	min	max
Total Program Run Time (ms)	2956837	-	-	-	-	-
App Domains Created	1	-	-	-	-	-
App Domains Unloaded	1	-	-	-	-	-
Assemblies Loaded	8	-	-	-	-	-
Classes Loaded	975	-	-	-	-	-
Methods Loaded	3015	-	-	-	-	-
Closed Types Loaded	75	-	-	-	-	-
Closed Types Loaded per Definition	75	3	22	3	1	10
Open Types Loaded	13	-	-	-	-	-
Closed Methods Loaded	3	-	-	-	-	-
Closed Methods Loaded per Definition	3	1	3	1	1	1
Open Methods Loaded	0	-	-	-	-	-
Threads in Thread Pool	-	0	2	0	0	1
Pending Timers	-	0	4	0	0	1
Scheduled Timers	2	-	-	-	-	-
Timers Delayed by Thread Pool Limit	0	-	-	-	-	-
Work Items Queued	2	-	-	-	-	-
Uncontested Monitor.Enter Calls	664	-	-	-	-	-
Contested Monitor.Enter Calls	0	-	-	-	-	-
Peak Bytes Allocated (native + managed)	2789048	-	-	-	-	-
Managed Objects Allocated	25883	-	-	-	-	-
Managed Bytes Allocated	1366120	24	25883	52	8	135796
Managed String Objects Allocated	5360	-	-	-	-	-
Bytes of String Objects Allocated	124412	-	-	-	-	-
Garbage Collections (GC)	1	-	-	-	-	-
Bytes Collected By GC	897140	897140	1	897140	897140	897140
Managed Bytes In Use After GC	-	147292	1	147292	147292	147292
Total Bytes In Use After GC	-	2621848	1	2621848	2621848	2621848
GC Compactions	0	-	-	-	-	-
Code Pitchings	0	-	-	-	-	-
Calls to GC.Collect	0	-	-	-	-	-
GC Latency Time (ms)	46	46	1	46	46	46
Pinned Objects	0	-	-	-	-	-
Objects Moved by Compactor	0	-	-	-	-	-
Objects Not Moved by Compactor	0	-	-	-	-	-
Objects Finalized	82	-	-	-	-	-
Boxed Value Types	3273	-	-	-	-	-
Process Heap	-	1280	7484	198308	72	330016
Short Term Heap	-	0	6382	963	0	42136
JIT Heap	-	0	6402	421097	0	876976
App Domain Heap	-	0	18679	324926	0	523240
GC Heap	-	0	30	527974	0	1060864
Native Bytes Jitted	844928	208	1963	430	84	9684
Methods Jitted	1963	-	-	-	-	-
Bytes Pitched	0	0	0	0	0	0
Methods Pitched	0	-	-	-	-	-
Method Pitch Latency Time (ms)	0	0	0	0	0	0
Exceptions Thrown	4	-	-	-	-	-
Platform Invoke Calls	0	-	-	-	-	-
COM Calls Using a vtable	0	-	-	-	-	-
COM Calls Using IDispatch	0	-	-	-	-	-
Complex Marshaling	367	-	-	-	-	-
Runtime Callable Wrappers	0	-	-	-	-	-
Socket Bytes Sent	0	-	-	-	-	-
Socket Bytes Received	0	-	-	-	-	-
Controls Created	13	-	-	-	-	-
Brushes Created	23	-	-	-	-	-
Pens Created	8	-	-	-	-	-
Bitmaps Created	16	-	-	-	-	-
Regions Created	0	-	-	-	-	-
Fonts Created	7	-	-	-	-	-
Graphics Created (FromImage)	0	-	-	-	-	-
Graphics Created (CreateGraphics)	0	-	-	-	-	-

Next time, I'll post the final installment of this series which will discuss the Windows.Forms counters.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Monitoring Application Performance on the .NET Compact Framework Part VII - Version 2 performance counters (Part V: JIT Compiler counters)

DavidKlineMS — Tue, 06 Dec 2005 22:29:00 GMT

Today's post is the fifth in the series of .NET Compact Framework v2 performance counters. For a complete listing of the previous installments, please see the list below.

Pre-requisite:
Monitoring Application Performance on the .NET Compact Framework Part I - Enabling performance counters
.NET Compact Framework Version 1:
Monitoring Application Performance on the .NET Compact Framework Part II - Version 1 performance counters
.NET Compact Framework Version 2:
Monitoring Application Performance on the .NET Compact Framework Part III - Version 2 performance counters (Part I: Loader counters)
Monitoring Application Performance on the .NET Compact Framework Part IV - Version 2 performance counters (Part II: Generics counters)
Monitoring Application Performance on the .NET Compact Framework Part V - Version 2 performance counters (Part III: Locks and Threads counters)
Monitoring Application Performance on the .NET Compact Framework Part VI - Version 2 performance counters (Part IV: Garbage Collector counters)

The following table lists all of the performance counters available in version 2 of the .NET Compact Framework. The counters highlighted, in yellow, are the ones I will be talking about today.

Loader
	Total Program Run Time (ms)
	App Domains Created
	App Domains Unloaded
	Assemblies Loaded
	Classes Loaded
	Methods Loaded
Generics
	Closed Types Loaded
	Closed Types Loaded per Definition
	Open Types Loaded
	Closed Methods Loaded
	Closed Methods Loaded per Definition
	Open Methods Loaded
Locks and Threads
	Threads in Thread Pool
	Pending Timers
	Scheduled Timers
	Timers Delayed by Thread Pool Limit
	Work Items Queued
	Uncontested Monitor.Enter Calls
	Contested Monitor.Enter Calls
Garbage Collector
	Peak Bytes Allocated (native + manged)
	Managed Objects Allocated
	Managed Bytes Allocated
	Managed String Objects Allocated
	Bytes of String Objects Allocated
	Garbage Collections (GC)
	Bytes Collected By GC
	Managed Bytes In Use After GC
	Total Bytes In Use After GC
	GC Compactions
	Code Pitchings
	Calls to GC.Collect
	GC Latency Time (ms)
	Pinned Objects
	Objects Moved by Compactor
	Objects Not Moved by Compactor
	Objects Finalized
	Boxed Vlue Types
	Process Heap
	Short Term Heap
	JIT Heap
	App Domain Heap
	GC Heap
JIT Compiler
	Native Bytes Jitted
	Methods Jitted
	Bytes Pitched
	Methods Pitched
	Method Pitch Latency Time (ms)
Exceptions
	Exceptions Thrown
Interop
	Platform Invoke Calls
	COM Calls Using a vtable
	COM Calls Using IDispatch
	Complex Marshaling
	Runtime Callable Wrappers
Networking
	Socket Bytes Sent
	Socket Bytes Received
Windows.Forms
	Controls Created
	Brushes Created
	Pens Created
	Bitmaps Created
	Regions Created
	Fonts Created
	Graphics Created (FromImage)
	Graphics Created (CreateGraphics)

counter	total	last datum	n	mean	min	max
Total Program Run Time (ms)	2956837	-	-	-	-	-
App Domains Created	1	-	-	-	-	-
App Domains Unloaded	1	-	-	-	-	-
Assemblies Loaded	8	-	-	-	-	-
Classes Loaded	975	-	-	-	-	-
Methods Loaded	3015	-	-	-	-	-
Closed Types Loaded	75	-	-	-	-	-
Closed Types Loaded per Definition	75	3	22	3	1	10
Open Types Loaded	13	-	-	-	-	-
Closed Methods Loaded	3	-	-	-	-	-
Closed Methods Loaded per Definition	3	1	3	1	1	1
Open Methods Loaded	0	-	-	-	-	-
Threads in Thread Pool	-	0	2	0	0	1
Pending Timers	-	0	4	0	0	1
Scheduled Timers	2	-	-	-	-	-
Timers Delayed by Thread Pool Limit	0	-	-	-	-	-
Work Items Queued	2	-	-	-	-	-
Uncontested Monitor.Enter Calls	664	-	-	-	-	-
Contested Monitor.Enter Calls	0	-	-	-	-	-
Peak Bytes Allocated (native + managed)	2789048	-	-	-	-	-
Managed Objects Allocated	25883	-	-	-	-	-
Managed Bytes Allocated	1366120	24	25883	52	8	135796
Managed String Objects Allocated	5360	-	-	-	-	-
Bytes of String Objects Allocated	124412	-	-	-	-	-
Garbage Collections (GC)	1	-	-	-	-	-
Bytes Collected By GC	897140	897140	1	897140	897140	897140
Managed Bytes In Use After GC	-	147292	1	147292	147292	147292
Total Bytes In Use After GC	-	2621848	1	2621848	2621848	2621848
GC Compactions	0	-	-	-	-	-
Code Pitchings	0	-	-	-	-	-
Calls to GC.Collect	0	-	-	-	-	-
GC Latency Time (ms)	46	46	1	46	46	46
Pinned Objects	0	-	-	-	-	-
Objects Moved by Compactor	0	-	-	-	-	-
Objects Not Moved by Compactor	0	-	-	-	-	-
Objects Finalized	82	-	-	-	-	-
Boxed Value Types	3273	-	-	-	-	-
Process Heap	-	1280	7484	198308	72	330016
Short Term Heap	-	0	6382	963	0	42136
JIT Heap	-	0	6402	421097	0	876976
App Domain Heap	-	0	18679	324926	0	523240
GC Heap	-	0	30	527974	0	1060864
Native Bytes Jitted	844928	208	1963	430	84	9684
Methods Jitted	1963	-	-	-	-	-
Bytes Pitched	0	0	0	0	0	0
Methods Pitched	0	-	-	-	-	-
Method Pitch Latency Time (ms)	0	0	0	0	0	0
Exceptions Thrown	4	-	-	-	-	-
Platform Invoke Calls	0	-	-	-	-	-
COM Calls Using a vtable	0	-	-	-	-	-
COM Calls Using IDispatch	0	-	-	-	-	-
Complex Marshaling	367	-	-	-	-	-
Runtime Callable Wrappers	0	-	-	-	-	-
Socket Bytes Sent	0	-	-	-	-	-
Socket Bytes Received	0	-	-	-	-	-
Controls Created	13	-	-	-	-	-
Brushes Created	23	-	-	-	-	-
Pens Created	8	-	-	-	-	-
Bitmaps Created	16	-	-	-	-	-
Regions Created	0	-	-	-	-	-
Fonts Created	7	-	-	-	-	-
Graphics Created (FromImage)	0	-	-	-	-	-
Graphics Created (CreateGraphics)	0	-	-	-	-	-

Up next: Exception, Interop and Networking counters.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Monitoring Application Performance on the .NET Compact Framework Part VI - Version 2 performance counters (Part IV: Garbage Collector counters)

DavidKlineMS — Thu, 01 Dec 2005 21:08:00 GMT

Today's post is the fourth in the series of .NET Compact Framework v2 performance counters. For a complete listing of the previous installments, please see the list below.

Pre-requisite:
Monitoring Application Performance on the .NET Compact Framework Part I - Enabling performance counters
.NET Compact Framework Version 1:
Monitoring Application Performance on the .NET Compact Framework Part II - Version 1 performance counters
.NET Compact Framework Version 2:
Monitoring Application Performance on the .NET Compact Framework Part III - Version 2 performance counters (Part I: Loader counters)
Monitoring Application Performance on the .NET Compact Framework Part IV - Version 2 performance counters (Part II: Generics counters)
Monitoring Application Performance on the .NET Compact Framework Part V - Version 2 performance counters (Part III: Locks and Threads counters)

The following table lists all of the performance counters available in version 2 of the .NET Compact Framework. The counters highlighted, in yellow, are the ones I will be talking about today.

Loader
	Total Program Run Time (ms)
	App Domains Created
	App Domains Unloaded
	Assemblies Loaded
	Classes Loaded
	Methods Loaded
Generics
	Closed Types Loaded
	Closed Types Loaded per Definition
	Open Types Loaded
	Closed Methods Loaded
	Closed Methods Loaded per Definition
	Open Methods Loaded
Locks and Threads
	Threads in Thread Pool
	Pending Timers
	Scheduled Timers
	Timers Delayed by Thread Pool Limit
	Work Items Queued
	Uncontested Monitor.Enter Calls
	Contested Monitor.Enter Calls
Garbage Collector
	Peak Bytes Allocated (native + managed)
	Managed Objects Allocated
	Managed Bytes Allocated
	Managed String Objects Allocated
	Bytes of String Objects Allocated
	Garbage Collections (GC)
	Bytes Collected By GC
	Managed Bytes In Use After GC
	Total Bytes In Use After GC
	GC Compactions
	Code Pitchings
	Calls to GC.Collect
	GC Latency Time (ms)
	Pinned Objects
	Objects Moved by Compactor
	Objects Not Moved by Compactor
	Objects Finalized
	Boxed Value Types
	Process Heap
	Short Term Heap
	JIT Heap
	App Domain Heap
	GC Heap
JIT Compiler
	Native Bytes Jitted
	Methods Jitted
	Bytes Pitched
	Methods Pitched
	Method Pitch Latency Time (ms)
Exceptions
	Exceptions Thrown
Interop
	Platform Invoke Calls
	COM Calls Using a vtable
	COM Calls Using IDispatch
	Complex Marshaling
	Runtime Callable Wrappers
Networking
	Socket Bytes Sent
	Socket Bytes Received
Windows.Forms
	Controls Created
	Brushes Created
	Pens Created
	Bitmaps Created
	Regions Created
	Fonts Created
	Graphics Created (FromImage)
	Graphics Created (CreateGraphics)

The statistics file includes running totals, the most recent value (last datum), count (n), average (mean), minimum and maximum values for the counters. I've included an example file at the end of this post. For counters where a given column is not relevant, a hyphen (-) is logged.

I will use the following format to describe each counter.
Counter name
Brief description of the counter
Discussion of the contents of relevant columns (total, last datum, n, mean, min, max)
Any additional comments relating to the counter

Garbage Collector Counters
Today's counters relate to memory usage and the .NET Compact Framework Garbage Collector. From version 1 to version 2, the Garbage Collector counters have been refined a great deal. The version 2 counters provide significantly more detailed insight into application memory usage and make identifying memory related performance issues much easier.

For information on the .NET Compact Framework Garbage Collector, please see Steven Pratschner's post: An Overview of the .NET Compact Framework Garbage Collector.

Peak Bytes Allocated (native + managed)
The maximum number of bytes in use by the .NET Compact Framework including both native and managed memory.
total: The largest number of bytes used at any time during the runtime of the application

Managed Objects Allocated
The count of all managed objects that have been allocated (including unused objects).
total: Running total of managed objects allocated

Managed Bytes Allocated
The count of bytes allocated for managed objects.
total: Running total of bytes allocated
last datum: The size of the most recent allocation
n: The number of allocations
mean: The average size of the allocations
min: The smallest number of bytes allocated
max: The largest number of bytes allocated

Managed String Objects Allocated
The count of string objects that have been allocated.
total: Running total of managed string objects

Bytes of String Objects Allocated
The count of bytes allocated for managed string objects.
total: Running total of bytes allocated

Garbage Collections (GC)
The number of times the Garbage Collector ran during the run time of your application.
total: Running total of collections

Bytes Collected By GC
The count of bytes collected by the Garbage Collector.
total: Running total of bytes collected by the Garbage Collector
last datum: The size of the most recent collection
n: The number of collections
mean: The average size of the collections
min: The size of the smallest collection
max: The size of the largest collection

Managed Bytes In Use After GC
The number of bytes allocated to live objects after the Garbage Collector has run.
last datum: The number of managed bytes in use after the most recent collection
n: The number of collections
mean: The average number of bytes in use after the collections
min: The fewest number of bytes in use after a collection
max: The largest number of bytes in use after a collection

Total Bytes In Use After GC
The number of bytes (managed and native) in use after the Garbage Collector has run
last datum: The number of bytes in use after the most recent collection
n: The number of collections
mean: The average number of bytes in use after the collections
min: The fewest number of bytes in use after a collection
max: The largest number of bytes in use after a collection

GC Compactions
The number of times the Garbage Collector has compacted the heap.
total: Running total of heap compactions by the Garbage Collector

Code Pitchings
The number of times the Garbage Collector has pitched Just-In-Time (JIT) compiled code.
total: Running total of code pitchings

Calls to GC.Collect
The number of times the application has called the GC.Collect() method
total: Running total of calls to GC.Collect()
For a detailed discussion of the issues surrounding GC.Collect(), please see Scott Holden's post: The perils of GC.Collect.

GC Latency Time (ms)
The time (in milliseconds) that the Garbage Collector has taken to run.
total: Running total of time spent in collection
last datum: The time it took for the most recent collection to complete
n: The number of garbage collections
mean: The average time spent in collections
min: The shortest time it took to perform a collection
max: The longest time it took to perform a collection
Please note that the latency time of the Garbage Collector includes collection of managed objects which are no longer in scope and the compaction (if necessary) of the GC Heap.

Pinned Objects
The number of pinned objects that were encountered by the Garbage Collector.
total: Running total of pinned objects
Pinned objects are objects whose locations in memory cannot change. A good example of such an object is a memory buffer that is being used to communicate between managed and unmanaged (native) code. Pinned objects cannot be moved by the Garbage Collector during heap compaction.

Objects Moved by Compactor
The count of objects that were moved by the Garbage Collector during a compaction.
total: Running total of objects moved during compaction

Objects Not Moved by Compactor
The count of objects that cannot be moved or were not moved by the Garbage Collector during a compaction.
total: Running total of objects not moved during compaction
Objects might not be moved for a number of reasons. Some objects cannot be moved (this is rare). Other objects are not moved because they are in a portion of the heap which does not need to be compacted.

Objects Finalized
The number of objects for which a finalizer has been run.
total: Running total of finalized objects
More information on the Finalize method can be found in the .NET Programmers Reference on MSDN. A good discussion on implementing finalization in your objects can be found in the Implementing Finalize and Dispose to Clean Up Unmanaged Resources article (also on MSDN).

Boxed Value Types
The number of value types that have been boxed.
total: Running total of boxed value types
A good reference on boxing of value types can be found in the C# Programmers Reference on MSDN. Scott Holden also has a nice discussion on The cost of value types in the .NET Compact Framework.

Process Heap
The number of bytes in use by the .NET Compact Framework Common Language Runtime's default heap.
last datum: The current number of bytes in the heap
n: The number of allocations in the heap
mean: The average number of bytes in the heap
min: The smallest number of bytes in the heap (throughout the runtime of the application)
max: The largest number of bytes in the heap (throughout the runtime of the application)
The Process Heap contains memory allocated by the .NET Compact Framework's Common Language Runtime that does not fit into the other heaps (Short Term, JIT, App Domain, GC).

Short Term Heap
The number of bytes in use by the .NET Compact Framework Common Language Runtime's short term heap.
last datum: The current number of bytes in the heap
n: The number of allocations in the heap
mean: The average number of bytes in the heap
min: The smallest number of bytes in the heap (throughout the runtime of the application)
max: The largest number of bytes in the heap (throughout the runtime of the application)
The Short Term Heap contains memory allocated by the .NET Compact Framework Common Language Runtime for short lived (temporary) use.

JIT Heap
The number of bytes in use by the .NET Compact Framework Just-In-Time (JIT) compiler's heap.
last datum: The current number of bytes in the heap
n: The number of allocations in the heap
mean: The average number of bytes in the heap
min: The smallest number of bytes in the heap (throughout the runtime of the application)
max: The largest number of bytes in the heap (throughout the runtime of the application)
The JIT heap contains the native code generated when the .NET Compact Framework Just-In-Time compiler compiles a managed method. JIT compilation occurs whenever a managed method is executed for the first time (or the first time a method is executed after a code pitching).

App Domain Heap
The number of bytes in use by the .NET Compact Framework Common Language Runtime's App Domain heap.
last datum: The current number of bytes in the heap
n: The number of allocations in the heap
mean: The average number of bytes in the heap
min: The smallest number of bytes in the heap (throughout the runtime of the application)
max: The largest number of bytes in the heap (throughout the runtime of the application)
The App Domain Heap contains the dynamic representation of metadata used by the .NET Compact Framework Common Language Runtime's assembly loader.

GC Heap
The number of bytes in use by the .NET Compact Framework's Garbage Collector heap.
last datum: The current number of bytes in the heap
n: The number of allocations in the heap
mean: The average number of bytes in the heap
min: The smallest number of bytes in the heap (throughout the runtime of the application)
max: The largest number of bytes in the heap (throughout the runtime of the application)
The GC Heap contains memory allocated by applications and the .NET Compact Framework.

Example statistics file
I have highlighted the counters discussed here with a yellow background.

counter	total	last datum	n	mean	min	max
Total Program Run Time (ms)	2956837	-	-	-	-	-
App Domains Created	1	-	-	-	-	-
App Domains Unloaded	1	-	-	-	-	-
Assemblies Loaded	8	-	-	-	-	-
Classes Loaded	975	-	-	-	-	-
Methods Loaded	3015	-	-	-	-	-
Closed Types Loaded	75	-	-	-	-	-
Closed Types Loaded per Definition	75	3	22	3	1	10
Open Types Loaded	13	-	-	-	-	-
Closed Methods Loaded	3	-	-	-	-	-
Closed Methods Loaded per Definition	3	1	3	1	1	1
Open Methods Loaded	0	-	-	-	-	-
Threads in Thread Pool	-	0	2	0	0	1
Pending Timers	-	0	4	0	0	1
Scheduled Timers	2	-	-	-	-	-
Timers Delayed by Thread Pool Limit	0	-	-	-	-	-
Work Items Queued	2	-	-	-	-	-
Uncontested Monitor.Enter Calls	664	-	-	-	-	-
Contested Monitor.Enter Calls	0	-	-	-	-	-
Peak Bytes Allocated (native + managed)	2789048	-	-	-	-	-
Managed Objects Allocated	25883	-	-	-	-	-
Managed Bytes Allocated	1366120	24	25883	52	8	135796
Managed String Objects Allocated	5360	-	-	-	-	-
Bytes of String Objects Allocated	124412	-	-	-	-	-
Garbage Collections (GC)	1	-	-	-	-	-
Bytes Collected By GC	897140	897140	1	897140	897140	897140
Managed Bytes In Use After GC	-	147292	1	147292	147292	147292
Total Bytes In Use After GC	-	2621848	1	2621848	2621848	2621848
GC Compactions	0	-	-	-	-	-
Code Pitchings	0	-	-	-	-	-
Calls to GC.Collect	0	-	-	-	-	-
GC Latency Time (ms)	46	46	1	46	46	46
Pinned Objects	0	-	-	-	-	-
Objects Moved by Compactor	0	-	-	-	-	-
Objects Not Moved by Compactor	0	-	-	-	-	-
Objects Finalized	82	-	-	-	-	-
Boxed Value Types	3273	-	-	-	-	-
Process Heap	-	1280	7484	198308	72	330016
Short Term Heap	-	0	6382	963	0	42136
JIT Heap	-	0	6402	421097	0	876976
App Domain Heap	-	0	18679	324926	0	523240
GC Heap	-	0	30	527974	0	1060864
Native Bytes Jitted	844928	208	1963	430	84	9684
Methods Jitted	1963	-	-	-	-	-
Bytes Pitched	0	0	0	0	0	0
Methods Pitched	0	-	-	-	-	-
Method Pitch Latency Time (ms)	0	0	0	0	0	0
Exceptions Thrown	4	-	-	-	-	-
Platform Invoke Calls	0	-	-	-	-	-
COM Calls Using a vtable	0	-	-	-	-	-
COM Calls Using IDispatch	0	-	-	-	-	-
Complex Marshaling	367	-	-	-	-	-
Runtime Callable Wrappers	0	-	-	-	-	-
Socket Bytes Sent	0	-	-	-	-	-
Socket Bytes Received	0	-	-	-	-	-
Controls Created	13	-	-	-	-	-
Brushes Created	23	-	-	-	-	-
Pens Created	8	-	-	-	-	-
Bitmaps Created	16	-	-	-	-	-
Regions Created	0	-	-	-	-	-
Fonts Created	7	-	-	-	-	-
Graphics Created (FromImage)	0	-	-	-	-	-
Graphics Created (CreateGraphics)	0	-	-	-	-	-

In the next part of this series, I will talk about the .NET Compact Framework v2's JIT Compiler performance counters.

Take care,
-- DK

[Edit: post titles]

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Three Common Causes of Memory Leaks in Managed Applications

DavidKlineMS — Thu, 17 Nov 2005 00:28:00 GMT

One of the joys of working with managed code is not having to worry (as much) about memory management and letting the Garbage Collector do it's job. There are situations, however, when applications need to take a more active role in memory management. At MEDC 2005, I spoke, during my debugging session, about three common causes of memory leaks in managed applications:

Holding references to managed objects
Failing to release unmanaged resources
Failing to dispose Drawing objects

Holding references to managed objects
I do not actually consider the first of the three causes to be a leak in the truest sense of the term. I say this because the memory in question is accounted for by at least one valid reference within the current scope. While not a "true" leak, this can appear as one when looking at memory usage data.

When an application holds references longer than necessary, performance counters can show a steady increase in memory consumption and may, eventually, lead to an OutOfMemoryException. This situation can arise when variables never leave active scope. An example of this is an application that keeps track of large amounts of data in a class global collection. If at least one reference to a managed object remains in the current scope, the Garbage Collector cannot tell if your application is finished with the object. Since, as far as the GC can tell, the object is still in use, it cannot be marked for collection and therefore the memory is not freed. Since the memory is not freed the application's memory consumption continues to grow which looks very much like a memory leak.

Whenever possible, I recommend minimizing the scope of an object (local rather than class global variables). You can also let the Garbage Collector know you are finished with an object by setting your variable's value to null (Nothing in Visual Basic.NET) once you are finished using the object. This way, the GC can collect your unused objects at its earliest convenience and your application's memory consumption can be kept to a minimum.

Failing to release unmanaged resources
I mentioned, at the start of this post, that writing managed code largely frees you from needing to be concerned about memory management. This is true when you are using only managed objects. When you interoperate with native APIs (ex: via P/Invoke), your application needs to follow the native code memory management semantics -- loaded objects must be unloaded, allocated memory must be freed, etc.

A good example is the original version of the code in my post on getting the display color depth. While the code worked, there was a small memory leak. One of my readers kindly pointed out that I was forgetting to call ReleaseDC (I had previously called GetDC). This is a fairly common mistake, and I remember telling myself to not forget the call to ReleaseDC... While forgetting to call ReleaseDC is a relatively small leak, compared to forgetting to unload a large resource, these small leaks can build up quite rapidly. Whenever an application consumes unmanaged resources, I highly recommend a code review with another developer. I have found that walking someone through a block of code forces me to view it from a different angle and allows me to find these mistakes sooner.

The best source of information regarding proper handing of unmanaged resources is the API documentation. It has been my experience that the MSDN documentation does a good job at providing cleanup information for resources requiring cleanup, typically in the remarks section of the API reference.

Failing to dispose Drawing objects
A third common cause of memory leaks in managed applications is actually a manifestation of the previous cause. When consuming System.Drawing and Microsoft.WindowsMobile.DirectX.Direct3D objects, such as bitmaps, fonts, meshes and textures, it is important to call the object's Dispose method when you no longer need the object. This is important because, while these are managed objects, they contain references to unmanaged resources. These references are cleaned up (and the memory used is freed) when the object is disposed.

Methods of disposal
There are three methods for disposing of objects which require disposal.

Explicit call to the Dispose method
Example:
playerImage->Dispose();
Implicit via the C# using statement
Example:
using(SolidBrush brush = new SolidBrush(Color.Yellow)) { /* use the brush */ }
Finalization (not recommended)

Of these three disposal methods, two of them warrant further discussion.

Implicit disposal (C# using statement)
The documentation for the using statement states: "You create an instance in a using statement to ensure that Dispose is called on the object when the using statement is exited." This is a very handy way to ensure that objects requiring disposal get cleaned up properly. One drawback to disposal via the using statement is that all use of the object needs to be contained within the using statement's code block (within the curly braces { }). This is not a very serious drawback, however. In my experience, I rarely have need to use objects containing unmanaged resources (ex: System.Drawing.Bitmap) for more than a few lines of code -- in an OnPaint handler, for example.

If your application requires longer lived objects, explicitly calling the Dispose method when finished is the recommended approach.

Finalization (not recommended)
I do not recommend relying upon finalization to dispose of object requiring disposal for two reasons. The first reason is that the timing of finalization is not guaranteed. Finalization is performed at the discretion of the .NET Compact Framework runtime and can occur at any time in the future. While it is possible that finalization will occur soon after an object requiring disposal has been collected by the GC, it could also occur a significant time later. Secondly, an object's finalizer may not actually invoke its Dispose method. I would consider an object not calling Dispose as part of finalizationto contain a bug. While the bug would be in the object, it is the application which will likely get the report of the memory leak.

For a good discussion on implementing Dispose for your objects using unmanaged resources, please read Implementing Finalize and Dispose to Clean Up Unmanaged Resources (on MSDN).

This post has covered three common causes of memory leaks in managed applications. If you believe your application is encountering a leak, and you have been able to rule out these causes, please let us know about the issue via the Microsoft Product Feedback Center.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

[Edit: Cleanup: fix typeos, etc]

Monitoring Application Performance on the .NET Compact Framework Part V - Version 2 performance counters (Part III: Locks and Threads counters)

DavidKlineMS — Fri, 11 Nov 2005 01:55:00 GMT

This is the third part in the series describing .NET Compact Framework v2 performance counters. A complete listing of this series, to date, is included below.

Pre-requisite:
Monitoring Application Performance on the .NET Compact Framework Part I - Enabling performance counters
.NET Compact Framework Version 1:
Monitoring Application Performance on the .NET Compact Framework Part II - Version 1 performance counters
.NET Compact Framework Version 2:
Monitoring Application Performance on the .NET Compact Framework Part III - Version 2 performance counters (Part I: Loader counters)
Monitoring Application Performance on the .NET Compact Framework Part IV - Version 2 performance counters (Part II: Generics counters)

The following table lists all of the performance counters available in version 2 of the .NET Compact Framework. The counters highlighted, in yellow, are the ones I will be talking about today.

Loader
	Total Program Run Time (ms)
	App Domains Created
	App Domains Unloaded
	Assemblies Loaded
	Classes Loaded
	Methods Loaded
Generics
	Closed Types Loaded
	Closed Types Loaded per Definition
	Open Types Loaded
	Closed Methods Loaded
	Closed Methods Loaded per Definition
	Open Methods Loaded
Locks and Threads
	Threads in Thread Pool
	Pending Timers
	Scheduled Timers
	Timers Delayed by Thread Pool Limit
	Work Items Queued
	Uncontested Monitor.Enter Calls
	Contested Monitor.Enter Calls
Garbage Collector
	Peak Bytes Allocated (native + managed)
	Managed Objects Allocated
	Managed Bytes Allocated
	Managed String Objects Allocated
	Bytes of String Objects Allocated
	Garbage Collections (GC)
	Bytes Collected By GC
	Managed Bytes In Use After GC
	Total Bytes In Use After GC
	GC Compactions
	Code Pitchings
	Calls to GC.Collect
	GC Latency Time (ms)
	Pinned Objects
	Objects Moved by Compactor
	Objects Not Moved by Compactor
	Objects Finalized
	Boxed Value Types
	Process Heap
	Short Term Heap
	JIT Heap
	App Domain Heap
	GC Heap
JIT Compiler
	Native Bytes Jitted
	Methods Jitted
	Bytes Pitched
	Methods Pitched
	Method Pitch Latency Time (ms)
Exceptions
	Exceptions Thrown
Interop
	Platform Invoke Calls
	COM Calls Using a vtable
	COM Calls Using IDispatch
	Complex Marshaling
	Runtime Callable Wrappers
Networking
	Socket Bytes Sent
	Socket Bytes Received
Windows.Forms
	Controls Created
	Brushes Created
	Pens Created
	Bitmaps Created
	Regions Created
	Fonts Created
	Graphics Created (FromImage)
	Graphics Created (CreateGraphics)

counter	total	last datum	n	mean	min	max
Total Program Run Time (ms)	2956837	-	-	-	-	-
App Domains Created	1	-	-	-	-	-
App Domains Unloaded	1	-	-	-	-	-
Assemblies Loaded	8	-	-	-	-	-
Classes Loaded	975	-	-	-	-	-
Methods Loaded	3015	-	-	-	-	-
Closed Types Loaded	75	-	-	-	-	-
Closed Types Loaded per Definition	75	3	22	3	1	10
Open Types Loaded	13	-	-	-	-	-
Closed Methods Loaded	3	-	-	-	-	-
Closed Methods Loaded per Definition	3	1	3	1	1	1
Open Methods Loaded	0	-	-	-	-	-
Threads in Thread Pool	-	0	2	0	0	1
Pending Timers	-	0	4	0	0	1
Scheduled Timers	2	-	-	-	-	-
Timers Delayed by Thread Pool Limit	0	-	-	-	-	-
Work Items Queued	2	-	-	-	-	-
Uncontested Monitor.Enter Calls	664	-	-	-	-	-
Contested Monitor.Enter Calls	0	-	-	-	-	-
Peak Bytes Allocated (native + managed)	2789048	-	-	-	-	-
Managed Objects Allocated	25883	-	-	-	-	-
Managed Bytes Allocated	1366120	24	25883	52	8	135796
Managed String Objects Allocated	5360	-	-	-	-	-
Bytes of String Objects Allocated	124412	-	-	-	-	-
Garbage Collections (GC)	1	-	-	-	-	-
Bytes Collected By GC	897140	897140	1	897140	897140	897140
Managed Bytes In Use After GC	-	147292	1	147292	147292	147292
Total Bytes In Use After GC	-	2621848	1	2621848	2621848	2621848
GC Compactions	0	-	-	-	-	-
Code Pitchings	0	-	-	-	-	-
Calls to GC.Collect	0	-	-	-	-	-
GC Latency Time (ms)	46	46	1	46	46	46
Pinned Objects	0	-	-	-	-	-
Objects Moved by Compactor	0	-	-	-	-	-
Objects Not Moved by Compactor	0	-	-	-	-	-
Objects Finalized	82	-	-	-	-	-
Boxed Value Types	3273	-	-	-	-	-
Process Heap	-	1280	7484	198308	72	330016
Short Term Heap	-	0	6382	963	0	42136
JIT Heap	-	0	6402	421097	0	876976
App Domain Heap	-	0	18679	324926	0	523240
GC Heap	-	0	30	527974	0	1060864
Native Bytes Jitted	844928	208	1963	430	84	9684
Methods Jitted	1963	-	-	-	-	-
Bytes Pitched	0	0	0	0	0	0
Methods Pitched	0	-	-	-	-	-
Method Pitch Latency Time (ms)	0	0	0	0	0	0
Exceptions Thrown	4	-	-	-	-	-
Platform Invoke Calls	0	-	-	-	-	-
COM Calls Using a vtable	0	-	-	-	-	-
COM Calls Using IDispatch	0	-	-	-	-	-
Complex Marshaling	367	-	-	-	-	-
Runtime Callable Wrappers	0	-	-	-	-	-
Socket Bytes Sent	0	-	-	-	-	-
Socket Bytes Received	0	-	-	-	-	-
Controls Created	13	-	-	-	-	-
Brushes Created	23	-	-	-	-	-
Pens Created	8	-	-	-	-	-
Bitmaps Created	16	-	-	-	-	-
Regions Created	0	-	-	-	-	-
Fonts Created	7	-	-	-	-	-
Graphics Created (FromImage)	0	-	-	-	-	-
Graphics Created (CreateGraphics)	0	-	-	-	-	-

Take care,
-- DK

[Edit: update counter table to fix errors]
[Edit: post titles]

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Monitoring Application Performance on the .NET Compact Framework Part IV - Version 2 performance counters (Part II: Generics counters)

DavidKlineMS — Wed, 26 Oct 2005 00:47:00 GMT

In the previous installment, I discussed the .NET Compact Framework performance counters related to the loader. Today, I'd like to talk about the counters related to the new Generic feature of the .NET Compact Framework version 2.

This is the second part of the series describing .NET Compact Framwork v2 performance counters. A complete listing of this series, to date, is included below.

Pre-requisite:
Monitoring Application Performance on the .NET Compact Framework Part I - Enabling performance counters
.NET Compact Framework Version 1:
Monitoring Application Performance on the .NET Compact Framework Part II - Version 1 performance counters
.NET Compact Framework Version 2:
Monitoring Application Performance on the .NET Compact Framework Part III - Version 2 performance counters (Part I: Loader counters)

In each new installment, I will add to this list, to make referring back easier. I have also listed the earlier posts of the parent series on monitoring application performance.

The following table lists all of the performance counters available in version 2 of the .NET Compact Framework. The counters highlighted, in yellow, are the ones I will be talking about today.

Loader
	Total Program Run Time (ms)
	App Domains Created
	App Domains Unloaded
	Assemblies Loaded
	Classes Loaded
	Methods Loaded
Generics
	Closed Types Loaded
	Closed Types Loaded per Definition
	Open Types Loaded
	Closed Methods Loaded
	Closed Methods Loaded per Definition
	Open Methods Loaded
Locks and Threads
	Threads in Thread Pool
	Pending Timers
	Scheduled Timers
	Timers Delayed by Thread Pool Limit
	Work Items Queued
	Uncontested Monitor.Enter Calls
	Contested Monitor.Enter Calls
Garbage Collector
	Peak Bytes Allocated (native + managed)
	Managed Objects Allocated
	Managed Bytes Allocated
	Managed String Objects Allocated
	Bytes of String Objects Allocated
	Garbage Collections (GC)
	Bytes Collected By GC
	Managed Bytes In Use After GC
	Total Bytes In Use After GC
	GC Compactions
	Code Pitchings
	Calls to GC.Collect
	GC Latency Time (ms)
	Pinned Objects
	Objects Moved by Compactor
	Objects Not Moved by Compactor
	Objects Finalized
	Boxed Value Types
	Process Heap
	Short Term Heap
	JIT Heap
	App Domain Heap
	GC Heap
JIT Compiler
	Native Bytes Jitted
	Methods Jitted
	Bytes Pitched
	Methods Pitched
	Method Pitch Latency Time (ms)
Exceptions
	Exceptions Thrown
Interop
	Platform Invoke Calls
	COM Calls Using a vtable
	COM Calls Using IDispatch
	Complex Marshaling
	Runtime Callable Wrappers
Networking
	Socket Bytes Sent
	Socket Bytes Received
Windows.Forms
	Controls Created
	Brushes Created
	Pens Created
	Bitmaps Created
	Regions Created
	Fonts Created
	Graphics Created (FromImage)
	Graphics Created (CreateGraphics)

counter	total	last datum	n	mean	min	max
Total Program Run Time (ms)	2956837	-	-	-	-	-
App Domains Created	1	-	-	-	-	-
App Domains Unloaded	1	-	-	-	-	-
Assemblies Loaded	8	-	-	-	-	-
Classes Loaded	975	-	-	-	-	-
Methods Loaded	3015	-	-	-	-	-
Closed Types Loaded	75	-	-	-	-	-
Closed Types Loaded per Definition	75	3	22	3	1	10
Open Types Loaded	13	-	-	-	-	-
Closed Methods Loaded	3	-	-	-	-	-
Closed Methods Loaded per Definition	3	1	3	1	1	1
Open Methods Loaded	0	-	-	-	-	-
Threads in Thread Pool	-	0	2	0	0	1
Pending Timers	-	0	4	0	0	1
Scheduled Timers	2	-	-	-	-	-
Timers Delayed by Thread Pool Limit	0	-	-	-	-	-
Work Items Queued	2	-	-	-	-	-
Uncontested Monitor.Enter Calls	664	-	-	-	-	-
Contested Monitor.Enter Calls	0	-	-	-	-	-
Peak Bytes Allocated (native + managed)	2789048	-	-	-	-	-
Managed Objects Allocated	25883	-	-	-	-	-
Managed Bytes Allocated	1366120	24	25883	52	8	135796
Managed String Objects Allocated	5360	-	-	-	-	-
Bytes of String Objects Allocated	124412	-	-	-	-	-
Garbage Collections (GC)	1	-	-	-	-	-
Bytes Collected By GC	897140	897140	1	897140	897140	897140
Managed Bytes In Use After GC	-	147292	1	147292	147292	147292
Total Bytes In Use After GC	-	2621848	1	2621848	2621848	2621848
GC Compactions	0	-	-	-	-	-
Code Pitchings	0	-	-	-	-	-
Calls to GC.Collect	0	-	-	-	-	-
GC Latency Time (ms)	46	46	1	46	46	46
Pinned Objects	0	-	-	-	-	-
Objects Moved by Compactor	0	-	-	-	-	-
Objects Not Moved by Compactor	0	-	-	-	-	-
Objects Finalized	82	-	-	-	-	-
Boxed Value Types	3273	-	-	-	-	-
Process Heap	-	1280	7484	198308	72	330016
Short Term Heap	-	0	6382	963	0	42136
JIT Heap	-	0	6402	421097	0	876976
App Domain Heap	-	0	18679	324926	0	523240
GC Heap	-	0	30	527974	0	1060864
Native Bytes Jitted	844928	208	1963	430	84	9684
Methods Jitted	1963	-	-	-	-	-
Bytes Pitched	0	0	0	0	0	0
Methods Pitched	0	-	-	-	-	-
Method Pitch Latency Time (ms)	0	0	0	0	0	0
Exceptions Thrown	4	-	-	-	-	-
Platform Invoke Calls	0	-	-	-	-	-
COM Calls Using a vtable	0	-	-	-	-	-
COM Calls Using IDispatch	0	-	-	-	-	-
Complex Marshaling	367	-	-	-	-	-
Runtime Callable Wrappers	0	-	-	-	-	-
Socket Bytes Sent	0	-	-	-	-	-
Socket Bytes Received	0	-	-	-	-	-
Controls Created	13	-	-	-	-	-
Brushes Created	23	-	-	-	-	-
Pens Created	8	-	-	-	-	-
Bitmaps Created	16	-	-	-	-	-
Regions Created	0	-	-	-	-	-
Fonts Created	7	-	-	-	-	-
Graphics Created (FromImage)	0	-	-	-	-	-
Graphics Created (CreateGraphics)	0	-	-	-	-	-

Take care,
-- DK

[Edit: update counter table to fix errors]
[Edit: post titles]

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Monitoring Application Performance on the .NET Compact Framework Part III - Version 2 performance counters (Part I: Loader counters)

DavidKlineMS — Tue, 18 Oct 2005 20:03:00 GMT

Last time, I talked about the performance counters available in version 1 of the .NET Compact Framework. Today, I'd like to talk about a few of the performance counters available in version 2 of the .NET Compact Framework.

As I mentioned in part 1 (Enabling performance counters), the data collected is written to a file in the device's root folder when the application exits. In version 1 of the .NET Compact Framework, this file was called mscoree.stat. In version 2, the .NET Compact Framework the file's name is derived from your application (ex: WebCrawler.stat).

The following table lists all of the performance counters available in version 2 of the .NET Compact Framework.

Loader
	Total Program Run Time (ms)
	App Domains Created
	App Domains Unloaded
	Assemblies Loaded
	Classes Loaded
	Methods Loaded
Generics
	Closed Types Loaded
	Closed Types Loaded per Definition
	Open Types Loaded
	Closed Methods Loaded
	Closed Methods Loaded per Definition
	Open Methods Loaded
Locks and Threads
	Threads in Thread Pool
	Pending Timers
	Scheduled Timers
	Timers Delayed by Thread Pool Limit
	Work Items Queued
	Uncontested Monitor.Enter Calls
	Contested Monitor.Enter Calls
Garbage Collector
	Peak Bytes Allocated (native + managed)
	Managed Objects Allocated
	Managed Bytes Allocated
	Managed String Objects Allocated
	Bytes of String Objects Allocated
	Garbage Collections (GC)
	Bytes Collected By GC
	Managed Bytes In Use After GC
	Total Bytes In Use After GC
	GC Compactions
	Code Pitchings
	Calls to GC.Collect
	GC Latency Time (ms)
	Pinned Objects
	Objects Moved by Compactor
	Objects Not Moved by Compactor
	Objects Finalized
	Boxed Value Types
	Process Heap
	Short Term Heap
	JIT Heap
	App Domain Heap
	GC Heap
JIT Compiler
	Native Bytes Jitted
	Methods Jitted
	Bytes Pitched
	Methods Pitched
	Method Pitch Latency Time (ms)
Exceptions
	Exceptions Thrown
Interop
	Platform Invoke Calls
	COM Calls Using a vtable
	COM Calls Using IDispatch
	Complex Marshaling
	Runtime Callable Wrappers
Networking
	Socket Bytes Sent
	Socket Bytes Received
Windows.Forms
	Controls Created
	Brushes Created
	Pens Created
	Bitmaps Created
	Regions Created
	Fonts Created
	Graphics Created (FromImage)
	Graphics Created (CreateGraphics)

As you can see in the above table, there are quite a few performance counters available in version 2 of the .NET Compact Framework. Compared to version 1, the counters are more detailed, provide greater insight on the operation of the runtime and allow for a better understanding of application performance issues.

Considering the length of the previous post and the increased number of performance counters available in version 2, I will be discussing the new counters by their categories. With each new installment, I will re-post the above table, along with an example file, and highlight the counters being discussed by setting the background color to yellow.

The statistics file includes running totals, the most recent value (last datum), count (n), average (mean), minimum and maximum values for the counters. I've included an example file at the end of this post. For counters where a given column is not relevant, a hyphen (-) is logged.

I will use the following format to describe each counter.
Counter name
Brief description of the counter
Discussion of the contents of relevant columns (total, last datum, n, mean, min, max)
Any additional comments relating to the counter

Loader Counters
The first category of counters that I will cover are related to the loader. The loader is the portion of the runtime which is responsible for resolving and loading the components (assemblies, classes, etc) referenced by your application.

Total Program Run Time (ms)
The length of time your application ran (from the start of the Common Language Runtime).
total: Time in milliseconds

App Domains Created
The number of App Domains created in the application's process.
total: Running total of created App Domains

App Domains Unloaded
The number of App Domains that were unloaded during the run time of the application.
total: Running total of unloaded App Domains

Assemblies Loaded
The number of assemblies loaded (across all App Domains) on behalf of the application.
total: Running total of loaded assemblies

Classes Loaded
The number of classes loaded (across all App Domains) during the run time of the application.
total: Running total of loaded classes

Methods Loaded
The total number of methods loaded (across all App Domains) during the run time of the application.
total: Running total of loaded methods

If you are comparing the version 1 and version 2 counters, you may have noticed that version 2 no longer collects the Execution Engine Startup Time. Since applications cannot impact the Execution Engine's startup time, the counter is not relevant to application writers and was removed from version 2 of the .NET Compact Framework.

Example statistics file
The following is an example statistics file (formerly known as mscoree.stat) that shows the data collected by running a simple application.

As with the counters table, above, I have highlighted the counters discussed here with a yellow background. As this series continues, I will re-use this same example file and highlight the counters discussed in each post.

counter	total	last datum	n	mean	min	max
Total Program Run Time (ms)	2956837	-	-	-	-	-
App Domains Created	1	-	-	-	-	-
App Domains Unloaded	1	-	-	-	-	-
Assemblies Loaded	8	-	-	-	-	-
Classes Loaded	975	-	-	-	-	-
Methods Loaded	3015	-	-	-	-	-
Closed Types Loaded	75	-	-	-	-	-
Closed Types Loaded per Definition	75	3	22	3	1	10
Open Types Loaded	13	-	-	-	-	-
Closed Methods Loaded	3	-	-	-	-	-
Closed Methods Loaded per Definition	3	1	3	1	1	1
Open Methods Loaded	0	-	-	-	-	-
Threads in Thread Pool	-	0	2	0	0	1
Pending Timers	-	0	4	0	0	1
Scheduled Timers	2	-	-	-	-	-
Timers Delayed by Thread Pool Limit	0	-	-	-	-	-
Work Items Queued	2	-	-	-	-	-
Uncontested Monitor.Enter Calls	664	-	-	-	-	-
Contested Monitor.Enter Calls	0	-	-	-	-	-
Peak Bytes Allocated (native + managed)	2789048	-	-	-	-	-
Managed Objects Allocated	25883	-	-	-	-	-
Managed Bytes Allocated	1366120	24	25883	52	8	135796
Managed String Objects Allocated	5360	-	-	-	-	-
Bytes of String Objects Allocated	124412	-	-	-	-	-
Garbage Collections (GC)	1	-	-	-	-	-
Bytes Collected By GC	897140	897140	1	897140	897140	897140
Managed Bytes In Use After GC	-	147292	1	147292	147292	147292
Total Bytes In Use After GC	-	2621848	1	2621848	2621848	2621848
GC Compactions	0	-	-	-	-	-
Code Pitchings	0	-	-	-	-	-
Calls to GC.Collect	0	-	-	-	-	-
GC Latency Time (ms)	46	46	1	46	46	46
Pinned Objects	0	-	-	-	-	-
Objects Moved by Compactor	0	-	-	-	-	-
Objects Not Moved by Compactor	0	-	-	-	-	-
Objects Finalized	82	-	-	-	-	-
Boxed Value Types	3273	-	-	-	-	-
Process Heap	-	1280	7484	198308	72	330016
Short Term Heap	-	0	6382	963	0	42136
JIT Heap	-	0	6402	421097	0	876976
App Domain Heap	-	0	18679	324926	0	523240
GC Heap	-	0	30	527974	0	1060864
Native Bytes Jitted	844928	208	1963	430	84	9684
Methods Jitted	1963	-	-	-	-	-
Bytes Pitched	0	0	0	0	0	0
Methods Pitched	0	-	-	-	-	-
Method Pitch Latency Time (ms)	0	0	0	0	0	0
Exceptions Thrown	4	-	-	-	-	-
Platform Invoke Calls	0	-	-	-	-	-
COM Calls Using a vtable	0	-	-	-	-	-
COM Calls Using IDispatch	0	-	-	-	-	-
Complex Marshaling	367	-	-	-	-	-
Runtime Callable Wrappers	0	-	-	-	-	-
Socket Bytes Sent	0	-	-	-	-	-
Socket Bytes Received	0	-	-	-	-	-
Controls Created	13	-	-	-	-	-
Brushes Created	23	-	-	-	-	-
Pens Created	8	-	-	-	-	-
Bitmaps Created	16	-	-	-	-	-
Regions Created	0	-	-	-	-	-
Fonts Created	7	-	-	-	-	-
Graphics Created (FromImage)	0	-	-	-	-	-
Graphics Created (CreateGraphics)	0	-	-	-	-	-

Take care,
-- DK

[Edit: update counter table to fix errors]
[Edit: post title]

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.