Let me introduce myself



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.


Comments (3)

  1. Maxim Goldin, a developer who works on the profiling tools in Team System, has started blogging.


  2. Evgeny Goldin says:

    Way to go, brother ! I’m thinking about starting mine for a long time already ..

  3. Pavel Verevkin says:

    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.


    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

Skip to main content