mgoldin's blog

A blog about Profiler in Microsoft Visual Studio Team System 2005

Let me introduce myself

Hello,

 

I am Maxim Goldin, and I am a developer in Microsoft Visual Studio Team System 2005. More specifically – I spend all my working hours developing a profiler, which is a part of VSTS. I joined Microsoft in June 2003 after serving Intel Corporation in Israel for 8 years, and I am originally from Russia.

 

Profiling an application might be a non-trivial task; this is where I might and wish provide some help – either in running the tool, or understanding the results. I will be also grateful for any comments / suggestions about our tools – how to make them better and more user friendly, what are problems that you experienced with them, what functionality would you like to see there. Oh, and – just to mention it – I will not object to get positive comments as well J !

 

This is my first attempt to write a blog, and I find it quite exciting experience.

 

Published Monday, June 27, 2005 5:50 PM by mgoldin

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Rob Caron's Blog said:

Maxim Goldin, a developer who works on the profiling tools in Team System, has started blogging.
I...
June 27, 2005 4:37 PM
 

Evgeny Goldin said:

Way to go, brother ! I'm thinking about starting mine for a long time already ..
June 28, 2005 3:52 AM
 

Pavel Verevkin said:

Real-world experience.

Visual Studio 2005 Team Edition Service Pack 1.

Tiny C++ native application, single thread, 32-bit build. Basically 3 nested loops calling (originally) single ~200-line function with different parameters (60 mln times in total, original execution time - about 3 seconds). Looks like practically ideal case for a profiler.

Sampling does not work (Vista Ultimate 64 bit).

Instrumentation works. But there is no line-by-line information, so the information produced is completely useless. I had to spend a lot of my time refactoring the function, separating some potential bottllenecks into separate functions, and marking those separate functions __declspec(noinline) to make sure the information about them is gathered separately. This process skewed original results, increasing execution time by about 10% (despite the internal functions being marked as __fastcall and Global Optimization on), which is not acceptable by itself.

The new instrumented executable runs for several minutes (vs 3 sec), generating 11Gb VSP file. Visual Studio tries to analyze it for about half an hour, and crashes.

VSPerfReport.exe analyzes it for about half an hour and produces bunch of CSV files which are extremely cumbersome to work with, yet do not contain information detailed enough to be useful.

In case you are wondering, the computer it was run on is Dell Dimension 390 with 4-core processor and 15K RPM SCSI HDD - it does not get much better than this.

My previous experience with profilers (most recent - with Rational Quantify) was better by orders of magnitude.

CONCLUSION: The tool in its current state is absolutely useless.

SOLUTION:

1) Add the mode in which all of the counters exist per (runnuble) line of source code or even per machine instructions in the instrumented build

2) aggregate the counters (time and number of executions), instead of writing a transaction per execution

3) make the mode default.

Pavel Verevkin, Software Development Expert

Experian Decision Analytics

February 29, 2008 3:31 PM

Leave a Comment

(required) 
(optional)
(required) 
Submit

This Blog

Syndication

Tags

No tags have been created or used yet.

© 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker