First, let me say that I will follow up with a more detailed walkthrough of the product asap, so keep an eye out for it. Let me address some of your questions:
1. Profiling Overhead: This is of course application dependent and also platform dependent. For CPU-intensive phases of your application the overhead is negligible. Because tracing involves I/O, it can interfere with your I/O intensive applications. On some platforms, collecting callstacks is more expensive (e.g., x64 vs. x86). That's due to the calling conventions that are being used and the information necessary to walk the stack. I don't know of any profiling tool with zero impact, but this has thus far not been a source of feedback from customers. Do you have data to the contrary?
2. We actually sample on both context switches and at regular time intervals (1ms). So, we provide you with data about why threads blocked and where as well as data about what threads are doing when they're executing. You can get at the sample profile data by clicking on the "Execution" legend entry or by clicking on the execution segments in the time line. When you do the latter, we show you the sample callstack and give you a visual hint to where that sample was taken. Does this help?
3. We do have some support for PLINQ, TPL, and PPL. We show markers for PLINQ queries and some PPL and TPL parallel constructs that allow users to identify the region when they are executing so you can focus your tuning on them. Try it out! For PPL, you have to opt into this feature by calling the Concurrency::EnableTracing()/DisableTracing() methods.
4. I had a hard time parsing your comment about the active legend and the checkbox. Can you elaborate more? If this is a usability related question, I am very well aware of some of the warts in the product. We spent a huge amount of time improving the tool from that perspective. Look at our CTP, Beta 1, and Beta 2 bits and you'll agree that we've come a long way. We've also made significant investments in usability studies and worked with designers. We've learned a lot during this process and hope that we can avoid some of the pitfalls in future releases.
For more information about the tool, please visit my blog at http://blogs.msdn.com/hshafi. You might find some useful information there. I also have a detailed article in MSDN magazine at http://msdn.microsoft.com/en-us/magazine/ee336027.aspx.
Finally, Intel's Thread Profiler is very different from our tool in both methodology and diagnostic information provided in addition to our tool being fully integrated with the development experience. I don't want to get into a competitive analysis here, so choose what you find useful for your needs.