Yesterday I had a bug report from a client who had a user that was getting an exception report from their software which simply said “GetTempPath() - Failed to get temp path”. Now as error messages go this isn’t the best but it comes from some code that has been in my tools libraries for around 10 years and which has never failed before, it has no tests, we’re probably lucky that the message didn’t just read “TODO” as I’m pretty sure that it’s the first time that anyone has ever seen it apart from by reading my source code or running strings on an exe that includes my source code… Anyway…

I’m in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. The idea being that for certain specific usage scenarios the timer wheel will perform better than the timer queues. Last time I refactored the tests that I was using for the timer queues to remove duplication and I now have a set of failing tests for the new timer wheel.

The most recent articles in the “Practical Testing” series have been discussing the performance of the timer queue that we have built. Once I had got some new, optional, performance tests in place to measure what we were trying to improve I eventually came up with a new approach and began to implement a timer wheel that conforms to the interface used by the other implementations of my timer queue. Whilst doing this it became obvious that there was duplication in my test code and so the tests have been refactored to remove the duplication of the test code between CCallbackTimerQueue and CCallbackTimerQueueEx and, in addition, to create a full suite of tests for the new CCallbackTimerWheel class.

The most recent articles in the “Practical Testing” series have been discussing the performance of the timer queue that we have built. As I hinted when I first brought up the performance issues, the particular use case that I have which is causing problems might well be more efficiently dealt with using a different (more specialised and less general purpose) design. The timer queue has adequate performance for general purpose use and can handle timers set within a range of 0ms to 49.

I’m finding that the thread contention notation that I made up the other day to help me talk about the performance implications of the changes I was making is pretty useful. The definition needs adjusting slightly though… For a given lock the worst case contention is C. For an operation involving a single lock where t threads exist during the lifetime of the process and n threads access the lock the contention for the lock can be expressed as being C(n).

The previous article in the “Practical Testing” series set things up so that we can measure the performance of the code under test with the intention of trying to improve performance for a specific set of use case scenarios. This time around I’ll make a few changes which I hope will improve the performance and measure the effects of the changes with the performance tests that I added last time.

Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Since the original articles there have been several bug fixes and redesigns all of which have been supported by the original unit tests and many of which have led to the development of more tests.

I have been updating some client code to VS2010 and they use STLPort for the STL as it has better performance in multi-threaded situations than the version that comes with Visual Studio (see here). This has meant that I’ve needed to build STLPort 5.2.1 with VS2010 for x86 and x64. As with my previous builds of STLPort the compiler isn’t currently officially supported so I had to hack my installation to get it all to build, etc.

This is a handy tip from Jim Beveridge. It shows you how to add to the list of native function calls that the debugger steps over rather than into when you’re debugging in various flavours of Visual Studio. I wonder if the debugger picks up changes to the registry key whilst VS is running, if so there’s scope to build a little add-in that lets you add to the list from within VS…

As I mentioned yesterday, I’ve been doing some performance testing using the command line interface to perfmon to record the results. Today I automated the stuff I was playing with over the weekend and ended up with a script that can set up a perf log trace, install a particular build of a service, run a test from a remote client machine (using winrs) and then stop and remove the perf log and the service.