Perf Stats Per Extension
Provide high-level stats per extension (including internal features), so that users can self-diagnose performance issues.
Sometimes Visual studio is taking ages to load.
Monitor exactly what is happpening so that I can eventually disable or remove addins that I do not need or that are posing problems.
Adam Tybor commented
Totally agree with this!
The extensiblity story so much better now in VS, people seem to be using many more extensions. This is great for the ecosystem, but can cause **** for the developer. One poorly written extension can cause VS to come to a screeching halt.
It would be great if we could get some type of metrics or extension process monitor to see whats blocking, whats chewing cpu, whats hogging memory, etc. Being able to track down and find an extension causing performance problems is next to impossible today.
IE9 was able to something similar with their add-ons.
It would also be pie in the sky awesome if we could actually unregister MEF exports of specific extensions that were causing problems. So if for example some extension has a slow process for decorating my CSS color values with the annotated color, I could disable that hook explicitly. Often extension authors don't provide that fine grained ability to enable / disable options and its usually just a single poor hook causing problems, not the entire extension.
Some particular stats I would find valuable:
1) blocking the UI thread (great to see VS 11 really working on this, but extension authors may lag behind)
2) CPU usage, potentially breaking out the UI thread CPU usage (extensions/addins/etc might be doing work on the UI thread that could better be done in the threadpool, only marshaling to the UI thread for updating controls)
3) memory usage, especially over time (some extensions seem to get out of hand with in-memory caching)
Complete total awesome bonus points for overlaying the per-extension time graphs here with VS events (like opening files, saving files, doing builds, etc) to help the user determine which particular actions might be causing a problem (since the user is unlikely to remember off-hand exactly how many minutes ago was that last build they did)