Over in the forums a handful of folks have pointed out that profiling WPF is less than seemless, and can be super-frustrating. Even with profiles in-hand, sometimes there isn’t a bunch non-WPFers can do without some guidance. One of my personal goals is to change that, and we’d like your feedback on what you’d like to see in the future.
First, let’s take a inventory of what tools you have today:
– Sample/Instrumentation-Based profiles. These are great if you work at Microsoft, or it’s fairly clear where the time is going. But if it isn’t, you need our help to sort through the problem.
– Perforator. Except for a handful of specific problems, this tool tells you more about what your bottleneck isn’t, than what it is. It’s great for diagnosing over-invalidation & software rendering, but if that’s not your problem, your left with the profile.
Here’s some new ideas we’ve been tossing around:
Adding / exposing more ETW events, & providing more documentation about what they measure. We use ETW a lot internally because it’s very automatable. ETW is great because it can ‘roll-up’ CPU usage into understandable chunks (e.g., by reporting the time spent in specific layout passes, rendering a rectangle, resolving bindings, etc.). Couple that data with documentation about what the event is measuring, and you almost have a insiders’ view into the system.
Expanding Perfortator to detect ‘known’ bottlenecks & causes. My biggest beef with Perforator is that it doesn’t tell you where time is going, it tells you where it isn’t going. Still, when it can identify a bottleneck, it’s worth it’s weight (or byte-count) in gold.
Profile walk-throughs where different system costs are explained, with a focus on how to optimize them. This would provide more of a contextual understanding than a direct diagnosis, but having context can really help.
I’d love to hear any other ideas you might have. Feel free to send me a mail with what your thinking.