Performance Tuning in .NET using StopWatch

No comments

Wednesday, January 28, 2009

There comes a time in a software developer’s life where his code becomes slow. Sometime it is even possible to state the exact revision or date that caused the performance decrease. Searching the source code for the usual suspects can be futile and frustrating, and then there is the tricky part of making sure the performance issue has been solved after a change has been made.

Don’t get me wrong – understanding code is a must, but there is much more to performance tuning then just reading the code searching and solving each “suspect” as discovered. I’ve witnessed many times a lot of effort being made to optimize a part of the code that was only called once in a moon.

Performance Analysis is the first order of business before an attempt of any optimization can be made.

There are a lot of tools in the market for exactly that purpose - to find where the application spends most of its time and the component (or components) that are responsible for most of the bottlenecks in the runtime.

In the (near?) future I plan to write a review of the available tools but in this post I’d like to address a different aspect of performance analysis – using simple benchmarking for research of alternatives once the performance hot spot has been discovered.

In .NET there are some well known performance pitfalls:

  • Needlessly using boxing/unboxing of value types when calling functions or while using object based collections (ArrayList, Hashtable etc.).
  • Multiple consecutives calls to WebServices to do a simple task.
  • Abuse of Database – a lot of reads and writes

And the list goes on…

Then only list bigger then that list is the list of possible Solutions. To determine which solution is better and even do small scale performance analysis a simple benchmarking would suffice.

In the past (.NET 1.1) I needed to create my own “high precision timer” using interop and CPU related Voodoo but since .NET 2.0 I throw all that away and use StopWatch for all of my benchmarking needs.

StopWatch intelligently uses a resolution based on whether the underlying hardware supports a high one or not, if not supported (not likely in computers from the last couple of years), the Stopwatch reverts to that provided by DateTime.

Using StopWatch is very simple:

  1. Create a new instance of StopWatch
  2. Use Start() and Stop() before and after the code under invetigation
  3. Use Elapsed property to retrieve the time that passed.
Stopwatch stopWatch = new Stopwatch();
// Run your code

// Get the elapsed time as a TimeSpan value.
TimeSpan ts = stopWatch.Elapsed;

In order to get accurate results I suggest running the code multiple times (i.e. 1000) to reduce “noises” and ignoring the 1st result that could be affected by the initial JITing of the code under test.

After  a while of benchmarking my code I learnt very interning performance improvements and pitfalls in the .NET and how much they effect my application. 

As a matter of fact I used stopwatch for determining the performance difference between List<T> and ArrayList .

How To run as 32bit executable on a 64bit machine

No comments

Thursday, January 22, 2009

One of the problems I've encountered while working on a x64 machine is that I need to run NUnit as 32bit if I want to run a test assembly that was compiled as a x86 assembly. In fact I had several similar occasions when I needed to run applications on my computer as 32bit executables.

For this exact purpose a CorFlags Conversion Tool (CorFlags.exe) tool was created.

Corflags was shipped with .NET Framework SDK (2.0) it is a tool that allows the user to view and configure the corflags section of a PE image (The corflags section of the file is where all the platform related data is stored).

Getting information for a .NET assembly is very easy just use start the visual studio command prompt and write: corflags.exe filename.

The output should look something like:


Version - .NET version that the binary was built with.

CLR Header - 2.0 means either 1.0 or 1.1 while 2.5 means 2.0.

PE & 32bit - The platform this binary was compiled to run with:

AnyCPU - PE = PE32 and 32bit = 0

X86 - PE = PE32 and 32Bit = 1

64-bit - PE = PE32+ and 32bit = 0

CorFlags - This is computed by OR’g specific flags to indicate whether the image is ILONLY, its bitness etc. and is used by the loader.

ILONLY - 0 if the managed assembly contains unmanaged code 1 otherwise.

Signed - whether this assembly was signed using a strong key.


We can change the values of those variables inside the corflags section by using the tool with one of its arguments - see corflags.exe MSDN page for more details.


To cut a long story short  - using /32bit+ argument a .NET executable can be set to run as a x86 application.

NUnit is a .NET executable and as such it can be set run as  x86 using corflags.exe /32bit+ nunit.exe and now I can use it to run tests as 32bit.

How to remove a setup package with a known uninstall bug

No comments

Sunday, January 11, 2009

Today was the 2nd time I managed to cause a machine at work to not be able to uninstall the project I've been working on.

During installation tests I "accidentally" deleted part of the registry and resulting in not being able to uninstall the MSI (because it wasn't there) and not being able to install a new version of the project ("project already exist") - AAAAAAAAAAHHHHHHHHHHHH!

I've tried using some of the uninstall tools (i.e. Revo Uninstaller) and even considered (briefly) re-writing part of the registry.

Luckily for me Before I could cause more damage I came across a blog post by Aaron Stebner - Trick for setup developers - how to remove a setup package with a known uninstall bug.


I've tried the first option and run "msiexec.exe /fvecmus my_product.msi" to Forcibly install a fixed version of the MSI and presto my machine was usable again.

One of my posts was linked from Stackoverflow

No comments

Monday, January 05, 2009

As you might know I'm currently working at Typemock. Since I've started working there I have the feeling that software developers do not fully understand Test Driven Development and those who do have a hard time understanding why they should use mocking/faking framework.

Beginner developers when deciding to learn how to use unit tests as part of their development have a hard time finding entry level tutorials that have a section about using mock objects and most tutorials that show how to use mock objects assume that the reader already know what they are and why to use them.

So I decided I needed to write a simple easy to understand tutorial that would explain how a software developer can start using TDD (with mocks). I published a post titled : Starting Test Driven Development using Typemock Isolator - Part 1 on Typemock's Blog with hopes it would help beginners in the TDD world.

Today one of my co-workers have sent me a link to a page in Stackoverflow  - How to Getting Started With Mocking And TDD where the post I wrote is offered by someone I never met as a resource for TDD beginners - and it made my day :)


That is exactly one of the reasons I've started blogging - I wanted to help fellow developers learn new technologies and methodologies.

Related Posts Plugin for WordPress, Blogger...