Since responsiveness is all about whether or not VS is keeping up
with the incoming message stream, it is fairly straightforward
engineering work to figure out how long any given message takes to
process. During Visual Studio 2010 SP1, we added some hooks into the
product so we could tell when processing a single message took too long.
We released an extension called PerfWatson that recognized
unresponsiveness and generated anonymous reports that we collected and
aggregated. You can read this earlier blog post
about how we used PerfWatson data during Visual Studio 11. One of the
most interesting things to know about PerfWatson for today’s post is
that it collects a mini heap dump which allows us to figure out what
Visual Studio code is running at a particular point during the delay.
PerfWatson has been an extremely valuable tool for understanding VS hangs, but the threshold we set for it and the dump files it collects are designed for general application responsiveness, not for interactions that must be immediate such as typing a character and seeing it appear on the screen. Collecting a dump is fast, but it’s not fast enough to repeat on a per-keystroke basis. We therefore built a more fine-grained measurement system we call Immediate Delay Tracker (IDT).
Read More
PerfWatson has been an extremely valuable tool for understanding VS hangs, but the threshold we set for it and the dump files it collects are designed for general application responsiveness, not for interactions that must be immediate such as typing a character and seeing it appear on the screen. Collecting a dump is fast, but it’s not fast enough to repeat on a per-keystroke basis. We therefore built a more fine-grained measurement system we call Immediate Delay Tracker (IDT).
Read More
No comments:
Post a Comment