MSDN Interview
September 1998
When Microsoft set out to create Visual Studio® 6.0 nearly two years ago, one of its key goals was to provide enterprise developers with better tools. One of the most innovative and important new enterprise tools it came up with is the Visual Studio Analyzer, available in the Enterprise Edition of Visual Studio 6.0.
To learn more about this new tool and what it can do, MSDN interviewed Martyn Lovell, a Microsoft software engineer who led the team that created Visual Studio Analyzer.
MSDN: What is the Visual Studio Analyzer, and what exactly does it do?
LOVELL: Visual Studio Analyzer is a new technology in Visual Studio 6.0 Enterprise Edition that allows you to understand the performance of distributed applications and debug and understand them better.
MSDN: Why did the Visual Studio team decide to build this tool?
LOVELL: When we looked at the problems of enterprise developers, we saw that they were building applications for which we had no good tools for understanding performance, no good tools for debugging. We also saw that these kinds of applications were creating hard problems for developers. So we looked at what we could do to the Windows® platform and Visual Studio to improve the situation. That was how we came up with Visual Studio Analyzer.
What we did was instrument the Windows platform. This is a radical change for an operating system platform, different from that available on any other system. We put hooks into several of the key Windows technologies, including COM, the COM transaction integrator, and data access technologies such as ADO, ODBC, and the OLE DB drivers for SQL Server™.
These hooks can fire events that we can record and use to understand the performance of an application. We built a tool in Visual Studio to record these events and provide information about what they signified.
The Visual Studio Analyzer isn't just about adding something to a tools suite, it's about an operating system vendor providing developers with the first instrumented platform.
MSDN: Why did Microsoft decide to put the Visual Studio Analyzer only in the Enterprise Edition of Visual Studio 6.0?
LOVELL: The most natural users of Visual Studio Analyzer are people who build large distributed enterprise applications. Such applications might have a server side built using Visual C++®, a middle tier built using Visual Basic®, and a Web-based client. The Analyzer is a good fit for these kinds of developers, who tend to use Visual Studio Enterprise Edition.
For a long time, the Visual Studio team focused on examining the needs of developers who work with more than one tool. The great thing about Visual Studio Analyzer, however, is it's not language-specific. It doesn't mind whether you are building your application in Visual Basic or Visual C++; it just understands your application as it runs. This is because we put our instrumentation for the Analyzer into the operating system, rather than into the languages.
MSDN: Can you elaborate on what kinds of applications are appropriate to analyze with this new tool?
LOVELL: Visual Studio Analyzer is targeted firmly at new Windows DNA applications, which have multiple tiers.
Visual Studio Analyzer doesn't replace traditional profiling or debugging tools; it's the first step toward understanding a problem. Visual Studio Analyzer lets you move to traditional tools once you know exactly where your problem is. It points to specific programs or components, which you can then use traditional tools to understand.
For example, say you have a classic Windows DNA application with a Web client, a middle tier, and a server database. It's running on three different machines, with maybe five or six different processes in the application.
If you discover a performance problem in that application, Visual Studio Analyzer will help you identify where the problem lies. Then you can use existing debuggers and profilers from Microsoft and third-party vendors to understand the problem in deep detail.
MSDN: How large a learning curve will developers face to figure out the Analyzer, since it's a new tool they haven't seen before?
LOVELL: We've worked hard to make Visual Studio Analyzer as easy to use as possible, given the vast amounts of data it has to process. But when you're dealing with a system that can handle millions of events coming from different machines, you can get a quite complicated view of your system and your data.
We've built a number of features into the user interface to allow developers to control the amounts of data they see, such as filtering out data that's not interesting. Nonetheless, Visual Studio Analyzer is not a tool for novices. But realistically, we don't expect to see novice development teams building Windows DNA-type applications. If you're building a three-tier application, there are probably several people on your team who will find Visual Studio Analyzer easy to use and a comfortable fit to the knowledge they already have.
MSDN: Don't a lot of tools that try to analyze applications provide too much data, or data that's confusing?
LOVELL: Yes. Many data-analysis tools let you record a lot of events about your application, but provide very little to help you analyze those events. Even the Windows system tool, PerfMon, often gives you a graph, but doesn't let you see that graph in context. So we've built a couple of great features into Visual Studio Analyzer that help you understand your data at a higher level.
One of the tasks Visual Studio Analyzer can do is draw a block diagram of your system based on the events that have occurred within it. This is a nontrivial task. It looks at events coming from different parts of the system. It knows what process they're coming from, it knows what machine they're coming from, and often it knows what component within your system they're coming from.
Then the Analyzer tries to draw a diagram of those boxes. Even better, it can animate the diagram. It can actually draw over the top of those boxes the events flowing through the system. This lets you replay the heartbeat of your system, understand what is calling what, and what's going on within your system.
We've also integrated PerfMon into the Visual Studio Analyzer, so you can record PerfMon events at the same time you record Analyzer events. If you see a spike in PerfMon, where say, memory usage goes up rapidly by 50 percent, you can use a graph to correlate that spike with the call tree of your application. You can see which of your components were running when that memory spike happened. Then you can run a detailed debugger or profiler on that piece, to understand where that memory spike is coming from in your application.
MSDN: When the Visual Studio Analyzer is running, does it hurt the performance of any applications that are also running at the same time?
LOVELL: The amount of impact the Analyzer has on the performance of your system depends on how many events you're choosing to measure and how much data is traveling around the different parts of your system.
The Analyzer generates network traffic as it collects events. However, we worked really hard with the teams that created the events being fired to ensure the Analyzer would have a minimal impact on applications. We wanted to make sure that when you stop measuring a piece of your system, the Analyzer stops having any impact on that piece of your system.
We also worked to make sure that when the Analyzer finished looking at your application, you could close the Analyzer and everything would go back to performing exactly the way it did before. Unlike traditional debuggers that make you shut down each process when you detach the debugger, you can detach the Analyzer from a running system and leave the system in the same exact state it was in before you launched the Analyzer. This gives developers a much better way of looking at real running systems.
But certainly, if the Analyzer records 200 PerfMon counters and thousands of events, it will impact the performance of your app. However, we believe that for real-world performance measurement, the Analyzer shouldn't have a substantial impact on performance.
MSDN: What other hooks into the operating system does Visual Studio Analyzer use, and which operating systems does it work with?
LOVELL: Visual Studio Analyzer has hooks into all three major operating platforms out there today from Microsoft: Windows 95, Windows 98, and Windows NT® 4.0. We also have hooks coming up in Windows NT 5.0.
The hooks are in places such as COM. It's very simple to instrument the operating system code of COM using Visual Studio Analyzer. COM is one of our best providers of events, and we get some of our best data from COM.
For Windows NT 4.0, the hooks will be distributed in Windows NT Service Pack 4. [Editor's note: Service Pack 4 is due out this fall.] If you use Visual Studio Analyzer, there's a great benefit to moving to Service Pack 4.
For Windows 95 and Windows 98, the hooks are in the new DCOM bits that we ship on the Visual Studio 6.0 CD.
MSDN: Was it a lot of work to develop the Visual Studio Analyzer? Did you lead the team that built this new tool?
LOVELL: Yes, I was development lead for the team, and yes, this was a major job, because we were building something that to our knowledge no one else had ever built before. We were building it on a tight time schedule, too. And we had to ask for changes to many parts of the operating system and Visual Studio 6.0.
We faced a lot of technical challenges in designing a tool that could deal with vast volumes of information and understand all that information. We didn't want the Analyzer to merely present developers with a list containing a million items. We wanted it to present them with a useful summary of that information, and I think we accomplished that. I think it's safe to say Visual Studio Analyzer is a breakthrough for this kind of tool.
Martyn Lovell is a Development Lead on the Microsoft Visual Studio Enterprise team. He led the efforts to build the Visual Studio Analyzer and add source control integration to Visual Studio 6.0.
Before joining Microsoft in 1996, he was a senior systems designer at Brameur Ltd., an IT consulting firm in his home country of England. He joined Microsoft as a member of the Visual C++ IDE team and has worked ever since in the Developer Tools Division, helping build both Visual Studio 97 and Visual Studio 6.0. He has built tools for automation, user-interface design, team development, debugging, databases, multimedia, and more.