MSDN Magazine - April 2008 - (Page 18)

heart of your program, the application’s performance profile has been set in stone. Choosing your algorithms further limits performance. Selecting interface contracts between various sub-components constrains performance still further. It is critical that you understand the costs of each of these early design decisions and make wise ones. Design is an iterative process. It is best to start with the cleanest, simplest, most obvious choice and work up a sketch of the design (I actually recommend a prototype of the hot code) and evaluate the performance of that. You should also think about what the design would look like if you were to make performance the only factor, and then estimate how fast that application would be. Design is an iterative Now the fun engineering process. It is best to start begins! You start tinkering with the design and thinkwith the cleanest, simplest, ing about alternatives bemost obvious choice. I tween these two extremes, actually recommend a looking for designs that give prototype of the hot code. you the best result. Again, my experience with the profile data processor is instructive. Like most projects, my choice of data representation was critical. Should the data be in-memory? Should it be streamed over in a file? Should it be in a database? The standard solution is that any large dataset should be stored in a database; however, databases are optimized for relatively slow change, not for having large volumes of data changing frequently. My application would be dumping many gigabytes of data into the database routinely. Could the database handle this? With just a bit of measurement and analysis of database operations, it was easy to confirm that databases did not have the performance profile I needed. After some more measurements on how much memory an application can use before inducing excessive page faulting, I ruled out the in-memory solution as well. That left streaming data from a file for my basic data representation. There were still many other design decisions to be made, however. The basic form of the profile data is a list of heterogeneous events. But what should events look like? Are they strings (which are nicely uniform)? Are they C# structs or objects? If they are objects, the obvious solution is to make one allocation per event, which is a lot of allocations. Is that acceptable? How exFigure 1 Measuring Various Operations with MeasureIt.exe Operation Measured MethodCalls: EmptyStaticFunction() [count=1000 scale=10.0] MethodCalls: aClass.Interface() [count=1000 scale=10.0] ObjectOps: new Class() [count=1000 scale=10.0] Arrays: aIntArray[i] = 1 [count=1000 scale=10.0] Delegates: aInstanceDelegate() [count=1000 scale=10.0] PInvoke: FullTrustCall() [count=1000] Locks: Monitor lock [count=1000] Median actly does dispatch work as I iterate over the events? Is it a callback model or an iteration model? Does dispatch work through interfaces, delegates, or reflection? There were dozens of design decisions to be made, and they all would have impact on the ultimate performance of the program, so I needed to take measurements to understand the tradeoffs. The Logistics of Measuring Clearly you will be doing a lot of measuring during design. So exactly how do you do that? There are many profiling tools that can help, but one general-purpose technique that’s also the simplest and most available is micro-benchmarking. The technique is simple: when you want to know how much a particular operation costs, you simply set up an example of its use and directly measure how much time the operation takes. The .NET Framework has a high-resolution timer called System.Diagnostics.Stopwatch that was designed specifically for this purpose. The resolution varies with your hardware, but it typically has a resolution of less than 1 microsecond which is more than adequate. Since this comes with the .NET Framework, you already have the functionality you need. While Stopwatch is a great start, a good benchmark harness should do more. Small operations should be placed in loops to make the interval long enough to measure accurately. The benchmark should be run once before taking a measurement to ensure that any just-in-time (JIT) compilation and other one-time initialization has completed (unless, of course, the goal is to measure that initialization). Since measurements are noisy, the benchmark should be run several times and statistics should be gathered to determine the stability of the measurement. It should also be easy to run many benchmarks (design variations) in bulk and get a report that displays all the results for comparison. I have written a benchmark harness called MeasureIt.exe which builds upon the Stopwatch class and addresses these goals. It is available with the code download for this column on the MSDN® Magazine Web site. After unpacking, simply type the following in order to run it: MeasureIt Within seconds it will run a set of more than 50 standard benchmarks and display the results as a Web page. An excerpt of the data is shown in Figure 1. In these results, each measurement performs an operation 10,000 times (the operation is cloned 10 times in a Mean 1.005 1.769 8.040 0.638 1.244 6.946 12.129 StdDev 0.084 0.090 3.556 0.071 0.088 0.804 0.901 Min 0.922 1.696 5.087 0.612 1.160 5.878 11.322 Max 1.136 1.943 16.296 0.850 1.398 7.913 13.843 Samples 10 10 10 10 10 10 10 1.000 1.699 6.248 0.616 1.233 7.452 11.487 18 msdnmagazine CLR Inside Out

Table of Contents Feed for the Digital Edition of MSDN Magazine - April 2008

MSDN Magazine - April 2008 Contents Toolbox CLR Inside Out Basic Instincts Cutting Edge Foundations Test Run Service Station Windows with C++ Going Places { End Bracket }

MSDN Magazine - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.