I'm interested in hearing from users about what you like to use in VTune as well as what you find difficult to use. And while you're at it, tell me what you never use. Thanks, Mary
My biggest difficulty with Windows Vtune is the extent to which it gets thrown off by a corrupted .pdb. The only suggested work-around I have seen for .pdb corruption is to save the pre-processed source and attempt to build a .pdb directly from the pre-processed source. This is a large problem for me.
I imagine that some progress could be made by splitting the source files into smaller files, if it didn't run into build complications, where there are too many files to link in one step. The suggested work-around I know of for that is to build a tree of .dll's, which is a solution I'm not ready to attempt unless it happened to be the customer's preferred solution. The hope would be that .pdb corruption would be isolated into less important segments of the application. I still fear that it would break VTA; it seems that I most want VTA when it doesn't "just work."
Most used features have been cache and alignment related stall event counters, and Thread Checker. For long running applications, I use the feature of delaying sampling. It's useful to have a way to take repeatable samples out of the middle of an application, preferably without inserting Vtune API calls. I find it still somewhat difficult to diagnose Write Combine buffer related stalls, at least when using documented Vtune features.Call graph profiles are so much easier to get with gprof, that I avoid using Vtune for that, by changing compiler or OS.I know it's hard to cover the territory of uses to the extent Vtune aims to do.
Thanks for feedback and suggested work around with the corrupted .pdb's; we'll look into that further. Thanks, too, for info on your most-used features.
I hope that when you run into specific failures in your work environment that you are opening Premier cases on them! Our support engineers and developers are eager to figure how VTune can better serve our customers, and what you are describing does not sound common to me at all.
Also, keep in mind that it may be that your fears could translate into some thing rather simple, such as a corrupt installation or some slightly off environmental variable.
When you find issues with VTA, open the case. (And, if it turns out to be a nice, juicy, legit bug, we may NAME it after you!)
Here what I find in the article:"Accelerating .NET* Applications with the Intel VTune? Performance Analyzer 6.1" By Alan Zeichick
"One of my favorite uses of the Intel VTune Performance Analyzer is to run it twice-the first with the application running with a minimal test load, and the second time with it handling many transactions-and then compare the differences using Call Graph. The new version 6.1 makes that easy by having a built-in viewer for comparing the results of multiple execution runs. By spending a little time with Intel VTune Performance Analyzer, you can figure out which parts are scaling predictably nicely at O(n), which are a little worrisome at O(n log n), and which are behaving at an unfortunate O(n^2). And therefore, which parts might be poorly architected for a real-world Web transaction server."
Message Edited by intel.software.network.support on 12-09-2005 01:51 PM
Great tip - thanks for sharing your find.