Instrumentation in the .NET Compact Framework

So my boss, Mike Zintel, has showed me up. He started his blog and wrote this great article on memory management in the .NET Compact Framework and Windows CE. Don’t miss this one!

In any case, between reading the article and talking to Mike, I feel pretty guilty about the tools that we provide for our customers to tell how their app is performing. In v1 and even as we finish off v2, we really only have mscoree.stat to help out developers. See Developing Well Performing .NET Compact Framework Applications article if you would like more information on this. Mscoree.stat provides a simple static view of some counters in the .NET Compact Framework CLR at the end of the application run. Useful, but understandably not enough in many circumstances to find real issues.

First off, I want to enhance the counters in mscoree.stat. We have already added more information such as “Boxed Value Types” and the team is in the process of adding information about Windows.Forms, such as the number of controls, pens, etc.

The second thing is being able to take a live view of the mscoree.stat data – remote performance counters for the .NET Compact Framework. I have a prototype working today as you can see with the following picture. Basically this is just a runtime representation of the data from mscoree.stat over a network connection and displayed in a list view.

The application also publishes the data to PerfMon. The data that I am displaying in my sample instance below are the 5 memory heaps in the .NET Compact Framework and their current size while playing a game of Yahtzee. Throughout the game, you can see the GC Heap memory climbing since a GC does not occur. The large drop about two thirds of the way is from switching the application into the background. Here, we see that a full garbage collection occurs, including pitching JIT compiled code, significantly reducing the working set of the application while in the background. I then switched back to the application and resumed playing the game. This is only a simple sample of the data that can be gathered via remote performance counters.

We will get this stuff out in your hands as soon as possible – hopefully in the .NET Compact Framework 2.0 timeframe.

Scott

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

Comments

• Anonymous
  December 27, 2004
  I am super excited about this. Please update your screen shots with higher res images so we can drool on them as well rather than just the words :-) Is there a complete list of the new perf counters with CF 2.0? I have already found a bunch of new ones compared to CF 1.0 and listed them here:
  http://www.danielmoth.com/Blog/2004/08/performance-statistics-for-netcf-apps.html
  
  When you say “live view”, I take it you mean as the app is running and not having to wait for it to exit, right? This is exactly what is missing today! Will it also save data if the app crashes (at the moment if a CF app dies the stats file is empty)? The other limitation today is collecting data for two CF apps running at the same time… addressing that would be a bonus ;-)
  
  Also, now that you let the cat out of the bag, you won't get away with: "hopefully in the NETCF 2.0 timeframe" - we want this definitely for the CF 2.0 timeframe :-)

• Anonymous
  January 18, 2008
  I have seen different people looking for a dot.net profiler able to analyse their .Net Compact Framework applications. It is understandable that people look to solve issues within this arena since nowadays mobility is the trend. In the article, Instru

• Anonymous
  June 18, 2009
  PingBack from http://dotnet-profiler.com/wp/2008/01/dotnet-profiler-in-the-net-compact-framework/