Performance By Design

This is in response to a recent column from Wall Street Journal columnist Gordon Crovitz entitled “Who Really Invented the Internet?” This column is so misinformed and misguided that it is difficult to even know where to begin to try to correct the public record. However, I will give it a try. I am hardly the only one taking exception to the Crovitz column. The LA Times just published a rebuttal from author Michael Hilzik , whose book Crovitz cites in his column. In his LA Times article, Hilzik reports, "“My book bolsters, not contradicts, the argument that the Internet had its roots in the ARPANet, a government project.” So Crovitz's willful misinterpretation of the historical record is even more egregious than I first thought. Al Gore and the Internet. Let’s first take note of the echo of the partisan criticism leveled at Al Gore back during the Bush II-Gore 2000 election era of raucous partisan politics, ridiculing Gore for claiming that he invented the Internet....

This blog post describes the Scenario instrumentation library, a simple but useful tool for generating response time measurements from inside a Windows application. The Scenario instrumentation library uses QPC() and QTCT(), the Windows APIs discussed in an earlier blog entry , to gather elapsed times and CPU times between two explicit application-designated code markers. The application response time measurements are then written as ETW events that you can readily gather and analyze.  You can download a copy of the Scenario instrumentation library here at http://archive.msdn.microsoft.com/Scenario . The Scenario class library was originally conceived as a .NET Framework-flavored version of the Application Response Measurement (ARM) standard , which was accepted and sponsored by the Open Group. The idea behind ARM was that adding application response time measurements to an application in a standardized way would promote 3rd party tool development. Thi...

Some news that regular readers of this blog might be interested in hearing about... I plan to present two sessions at the upcoming UKCMG annual conference, which is being held this year on May 14 & 15 at the Oxford Belfry on the outskirts of Oxford, England. The first presentation is a repeat performance of the one I gave at the US CMG in December, a paper entitled   “Measuring Processor Utilization in Windows and Windows applications,” essentially pulling together the series of blog entries I have been posting here, beginning with the first installment , but with a good deal more material than I have gotten around to posting to the blog. For instance, the last blog post discussing the high resolution clocks and timer facilities in Windows leads directly to a consideration of what happens to the various CPU utilization measurements when Windows is running as virtual guest under VMware or Hyper-V. That discussion is in the paper, but, unfortunately, hasn’t made it to t...

This blog entry comes from answering the mail (note: names and other incriminating identification data were redacted to protect the guilty): A Reader writes: “My name is … and I am a developer for a software company. I encountered something I didn’t understand profiling our software and stumbled across your blog. Listen, hot-shot, since you are such an expert on this subject, maybe you can figure this out. Our software is very CPU-intensive, so we use QueryPerformanceCounter() and QueryPerformanceFrequency() to get the CPU cycles. Hence, if someone mistakenly commits some change to slow it down, we can catch it. It works fine until one day we decided to fire up more than one instance of the application. Since a large part of our code is sequential and could not be parallelized, by firing up another instance, we can use the other cores that are idle when one core is executing the sequential code. We found the timing profile all messed up. The time difference can be 5x difference ...

This content was moved to  http://computerperformancebydesign.com/using-querythreadcycletime-to-access-cpu-execution-timing/ .  Sorry for the inconvenience.

Within the discipline of software performance engineering (SPE), application response time monitoring refers to the capability of instrumenting application requests, transactions and other vital interaction scenarios in order to measure their response times. There is no single, more important performance measurement than application response time, especially in the degree which the consistency and length of application response time events reflect the user experience and relate to customer satisfaction. All the esoteric measurements of hardware utilization that Perfmon revels in pale by comparison. Of course, performance engineers usually still want to be able to break down application response time into its component parts, one of which is CPU usage. Other than the Concurrency Visualizer that is packaged with the Visual Studio Profiler that was discussed  in the previous post , there are few professional-grade, application response time monitoring and profi...