If you're a subscriber to msdn magazine, take a look at the article in the March 2008, Vol 23, No 4 issue on Page 81 which describes how to use the Visual Studio 2008 profiler to improve the performance of an application. A couple of members of the profiler team examine a Mandelbrot fractal drawing program in some detail. They isolate and fix several performance problems in the code, speeding up program execution approximately tenfold.

UPDATE: You can read the article here.

One of the new profiler features in Visual Studio Team System (VS2008) is called Noise Reduction. This feature is intended to make it easier to review the Call Tree view by reducing the amount of data that is displayed, while still showing the most important functions.

To illustrate this new feature I wrote a very simple native C++ application that utilizes TR1 in the Feature Pack Beta. In this simple app I create some shared_ptrs in a for loop after calling a recursive function a few times. If you're not familiar with TR1 take a look at the VC blog for more information.

   1: #include <tchar.h>

   2: #include <memory>

   3:  

   4: class A

   5: {

   6: public:

   7:     A(int v, int w) : b(v), c(w)

   8:     {}

   9: private:

  10:     int b;

  11:     int c;

  12: };

  13:  

  14: void recurse(int v)

  15: {

  16:     if (v > 0)

  17:     {

  18:         recurse(--v);

  19:     }

  20:     else

  21:     {

  22:         A someA(1,2);

  23:         for (int i=0; i < 100; ++i)

  24:         {

  25:             std::tr1::shared_ptr<int> a(new int(2));

  26:             std::tr1::shared_ptr<A> b(new A(2,3));

  27:             std::tr1::shared_ptr<A> c(b);

  28:         }

  29:     }

  30: }

  31:  

  32: int _tmain(int argc, _TCHAR* argv[])

  33: {

  34:     recurse(5);

  35:     return 0;

  36: }

I profiled the application using Instrumentation Mode as shown below. Shifting to 'Call Tree' view and expanding I see my main function, which calls recurse 6 times (the initial call from main plus 5 recursive calls from inside the if statement in recurse). There are also a lot of other calls that have very little inclusive time (e.g. __RTC_CheckESP).

To reduce the noise in the call tree I choose to enable noise reduction by clicking on the icon on the far right of the toolbar (it looks like a checklist). In the dialog I enable trimming, using a threshold of 3%.

After enabling this option I expand the call tree again and many of the extra calls are gone and the calls to recurse are much easier to see as shown below.

I still think I can do a little better so I open up the Noise Reduction dialog again and 'Enable Folding'.

The resulting call tree can now be completely expanded and shown without scroll bars. I can see that functions that have significant exclusive time include: __security_init_cookie (28.40%), shared_ptr setup for A, (10.23%), shared_ptr refcount destructor (11.30%) & the last call to recurse (7.58%).

Using Noise Reduction in a larger application should make it easier for you to find performance problems.

Details:

• Trimming removes leaf nodes in the call tree that have Elapsed Inclusive Time % (or Inclusive Sample % if you use sampling mode) lower than the threshold.
• Folding combines (folds) a child node up to its parent node if it is the only child and the Elapsed Inclusive Time % (or Inclusive Sample % if you use sampling mode) is within Threshold of its parent. The intention is to fold simple forwarding functions that don't have much influence on the performance of your code.

Trimming is applied first and then folding, which is why the calls to recurse are all folded.

Have you ever wanted to quickly run a C# application without having to setup a new project in Visual Studio and configure all the settings? A fellow developer here at Microsoft has written a tool called Code Runner .NET that allows just that. It isn't scripting exactly because the code is still compiled before being run instead of being interpreted, but you don't have to maintain project or solution files or worry about binaries. 

To try it out I downloaded the tool and installed it to c:\temp\csr. I created a file test.csr after referring to the Getting Started Guide:

   1: using System;

   2: using Microsoft.Tools.CodeRunner;

   3:  

   4: public class Program

   5: {

   6:     public static int Main(string[] args)

   7:     {

   8:         if (args.Length == 0)

   9:         {

  10:             // TODO: Fill out usage information

  11:             Console.WriteLine("Usage: {0}", ScriptEnvironment.ScriptPath.FileAndExtension);

  12:             return 0;

  13:         }

  14:  

  15:         // TODO: Script code goes here...

  16:  

  17:         return 0;

  18:     }

  19: }

My directory was completely empty aside from this file:

C:\temp\cr\mytest>dir /b
test.csr

I could then run the file as follows:

C:\temp\cr\mytest>..\csr test.csr
Usage: test.csr

That's it. The directory was still clean after the run:

C:\temp\cr\mytest>dir /b
test.csr

You can also debug your code in Visual Studio using a a nifty tool called scaffold which makes the requisite csproj and sln files and conveniently cleans up after we're done:

C:\temp\cr\mytest>..\Scaffold.exe test.csr
Response file 'C:\temp\cr\csc.rsp' processed
File 'C:\temp\cr\mytest\Scaffold_78D592CA\test.csproj' created
File 'C:\temp\cr\mytest\Scaffold_78D592CA\test.csproj.user' created
File 'C:\temp\cr\mytest\Scaffold_78D592CA\test.sln' created
Starting Visual Studio
Waiting for Visual Studio to exit

We can now debug as usual:

When Visual Studio closes:

Sub-directory 'C:\temp\cr\mytest\Scaffold_78D592CA\' was deleted

Code Runner .NET has already been updated to support Visual Studio 2008 so download it from CodePlex now.

I'm a member of IEEE and IEEE Computer Society and recently received requests to renew my subscriptions. I was pleasantly surprised to see that in 2008 student members of IEEE Computer Society can receive free software including Vista, Project, Visio and most interesting for me, Visual Studio Team System.

Both subscriptions come with monthly journals which are pretty technical and provide glimpses into various potential future career paths. 

UPDATE: If you're a student in the US, Australia or a few other places you can also get Office Ultimate 2007 for up to 90% off the retail price.

Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

We will be holding two sessions:

Join the chat on Wednesday, December 5th, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

                -and-

Join the chat on Wednesday, December 5th, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

--- 

I'll be in the Wed 4 pm - 5 pm chat to answer any questions related to profiling. Another member of the profiler team will be online for the earlier chat.

---

There are a lot of Microsoft bloggers, literally thousands of them. When I first joined Microsoft I wasn't sure who to read. I've gradually built up a list based on interesting product and feature announcements and people I've met. Here they are:

Profiling

• Our Team Blog
• IanWho's Blog. Written by a fellow dev on the profiler team, Ian has probably written the most about profiling across the team.
• joc's bLog. Written by my bosses' boss.
• mgoldin's blog. Written by a senior dev on my team. Find out about the difference between different types of samples etc.
• My Code Does What?!. A relatively new blog about profiling by another fellow dev.
• scarroll's Blog. Written by my boss.

Technical

• bharry's WebLog. Written by a Technical Fellow (read more about this) with a huge amount of experience who has a big focus on TFS.
• Greggm's Weblog. Written by a senior dev on the Debugger team. Has many advanced debugger tips.
• Mark Russinovich. Mark wrote some cool Sysinternals tools and now blogs some fascinating posts about his investigation into problems he finds everyday just using his PC.
• Rico Mariani's Performance Tidbits. Written by a senior Microsoftie who has been here for a long time. Gives tips for analyzing performance and provides guidelines to use in writing .NET code.
• ScottGu's Blog. Find out about LINQ, ASP.NET AJAX etc. etc. This blog has many examples including screenshots and source code.
• Somasegar's WebLog. As the corporate VP of DevDiv, Soma covers a lot of Visual Studio features and other developer tools.

Other

• Microsoft International Tech Jobs. I keep an eye on Microsoft's international opportunities here.
• Microsoft's JobsBlog. Discusses many aspects of Microsoft's recruiting. Covers the Vancouver office developments and has tips for prospective Microsofties.

That's just some of the Microsoft blogs I read. Are there other 'must-reads' that I'm missing?

I've been here at Microsoft for more than 6 months so I guess you could say that I've passed through the Honeymoon Phase. By now the initial joy and excitement should be starting to wear off and I should be settling into a monotonous routine.

Well I'm happy to say that it hasn't happened so far. I'm still learning a lot, including things like:

• Shipping big products is fun. We get to think about cool new ideas and some of them we implement and some of them get implemented by other smart folks.
• Shipping big products is hard. We have to worry about things like localization, corner case scenarios and crashes that smaller products just don't need to consider. All of this takes time and there can be periods of time where you're fixing strings or working in high-contrast mode.
• Our debugging tools are cool. For most of the bugs I need to fix my primary tool is Visual Studio. It is a good sign that even working with less stable dogfood versions is better than using another tool.
• Bug/Feature Triage is important. We have so many people using our products that all kinds of bugs are reported, from serious (crashes) to suggestion (please improve this feature by...). If we did everything that was asked of us, we would never have a stable version to release. However, triaging can be much more lenient in the early stages of development. Here we go through stages:
• Code review - any change you make must pass a code review. The reviewer might say 'hey, why are we fixing this bug!' and it may not be accepted.
• Tell mode - closer to a release our team leads will go along to a meeting (called a shiproom meeting) and they will say "hey, we're fixing these bugs". If a lead goes along and says "we changed the font size from 9 to 10 points" without a good reason there might be some raised eyebrows.
• Ask mode - even closer to release, before a bug is submitted, it has to go to the shiproom and be approved. Usually there are only certain classes of bugs that will be approved (blocking bugs, localization bugs, etc.). It is important that this 'bug bar' is known so that developers/leads know whether to attempt to fix a bug or not.
  
  All of this means that the number of bugs we fix gets fewer closer to a release, which means the product has time to stabilize and be thoroughly tested. At the same time, more minor bugs get a chance to get fixed early in the release cycle.
• Company Meetings are exciting. There was a lot of shouting, collective back-slapping and cool demos. It was amazing that 1/3 of a baseball stadium was all from the same company.
• Seattle summers are great. There is so much talk about how rainy Seattle is, but over summer the weather is warm but not really hot and it doesn't rain all that much. Daylight hours are long and it is perfect for getting out and about.

I also like hearing about new features and products and being able to try them out before they're distributed to customers. Let's see how the next 6 months go.

I've been thinking about what some of the most important tools are for me while coding. Here's a few:

• Good IDE - syntax highlighting, integrated builds, source control integration, search facility, debugger and profiler built-in. I use VSTS.
  
• Source control/bug tracking system. I use TFS (typically a dogfood version of TFS).
  
• Windows Task Manager.
  
  I use task manager to:
  - View CPU usage
  - Kill processes
  - Start a new explorer.exe if I ever kill explorer.exe. Do this from the Applications tab.
• Process Explorer.
   
  I use Process Explorer like task manager, but it can also:
  - Find what process has a handle (e.g. a file) open. This can be handy if you want to delete a file but a process has it locked.
  - Find out what DLLs a process has loaded
  - List the environment variables for a running process
• Process Monitor
  
  I use Process Monitor to record file, registry and process activity. This is very useful when debugging issues in complex programs like VSTS which have a lot of registry interactions.
• DebugView
  
  Display debugging output from programs without having to attach a debugger. This is very useful if you want to run your program outside a debugger and still want to see all those debug prints.
• Media Player. I like to listen to music while I code.
  
• Outlook. It is somewhat sad that I spend a fair percentage of my day reading emails, scheduling or checking up on meetings and writing notes in an Outlook journal, but I do and so I have Outlook open all the time.
• Internet Explorer. I need to use MSDN a lot and do web searches. I also read RSS feeds of relevant blogs with IE.
• Regedit.
• Remote Desktop. I work on different machines pretty regularly and Remote Desktop makes switching between machines easy.

In C++, memory allocated with the 'new' keyword must be deallocated using 'delete' or it is not deallocated until the application finishes. A call to delete results in a call to the destructor for that class. Classes that are allocated on the stack are automatically destroyed, which calls their destructor, when they go out of scope.

Sometimes this 'deterministic' memory allocation/deallocation behavior is exploited by developers using scoped objects on the stack to acquire and then automatically release resources even in the presence of exceptions (this pattern is known as Resource Acquisition Is Initialization - RAII).

Here is a C++ class designed to be used in RAII pattern:

class A
{
public:
   A()
   {
      // Acquire a resource (e.g. mutex or file)
   }

   ~A()
   {
      // Release the resource
   }
};

The class is then used as follows:

void f()
{
   {
      A raii;
      // do some stuff, maybe even throw exceptions
   }
   // raii has gone out of scope, so the destructor has been called. If an exception was thrown A still went out of scope and the destructor was still called
}

C# is a language with automatic garbage collection which means that developers allocate memory but in most cases they don't need to worry about when that memory is deallocated. There is no way to explicitly call the destructor. It is called whenever the garbage collector decides it is necessary to clean up, which is called Finalizing the class. In most cases classes should not implement a destructor.

In C#, it is possible to get somewhat deterministic garbage collection (at least for unmanaged objects like files) by implementing the IDisposable interface and adding a Dispose() method. That method acts much more like C++'s destructor than the equivalent class destructor. The dispose pattern is described pretty well for C# in the MSDN help for IDisposable.

Things to note:

• The C# destructor will only (and can only) be called by the Finalizer.
• Dispose() may be called in code.
• If Dispose() is called before the Finalizer is called, finalization is suppressed using GC.SuppressFinalize(this);.
• You must be careful not to reference any managed objects if Dispose is called from the destructor (this is achieved in the example by using an extra Dispose() function that takes a bool parameter).
• It isn't covered in the code, but if you have member variables that implement IDisposable, your class should also implement IDisposable.

Working with unmanaged resources is clearly much more work than working with managed resources.

To implement the same RAII pattern from above in C#, assuming you have set up your class A to implement IDisposable, code with the 'using' statement to ensure Dispose() is called at the end of the block as follows:

using (A raii = new A())
{
   // Do some stuff...
}

This is safe in the presence of exceptions in the same way that the C++ scoped class pattern was above.

Today we released Beta 2 of VS2008. This is the first public release from Microsoft that contains a nontrivial amount of code that I wrote (even though I haven't written too much code just yet). I had barely synched up the source tree and only fixed a couple of bugs when we released Beta 1 but now I've found my feet and am contributing more.

The major release announcements have focussed on the flashier (and admittedly very cool) aspects of the Beta like LINQ and some of the HTML editing and Javascript debugging features. However, us Profiler folks have also been toiling away adding new features and fixing bugs. Look out for things like (and some of these already featured in Beta 1, but they just keep getting better):

• A promotion to the new Developer menu
   
  
• Hot path - find the critical path/paths through your call trees
  
• Noise reduction - trim and/or fold your call trees so that they are easier to examine. See above for folding example.
• Comparison reports - compare subsequent profiler runs to determine if code changes are improving performance
  
• x64 OS support - profile on x64 Vista or W2K3 server 

If you can, please download it and let us know what you think. If you don't have the time at least take a look at the overview video showing some of the major features. You should also check out Ian's entry about controlling data collection while profiling. Hopefully I'll have time to go through some of the new profiler-specific features soon.