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.
Whilst profiling my new low contention buffer allocator in a ‘real world’ situation recently I spent quite a lot of time trying to work out what I was looking for and when it should happen. Since the allocator improves performance by reducing lock contention it only shines when there IS lock contention. I added some more monitoring to the existing buffer allocator so that it can give an indication of when it’s going to block during an allocation or release operation (by using TryEnterCriticalSection() followed by a monitoring notification and then an EnterCriticalSection() when the try has failed).
I’m continuing to help my performance obsessed client squeeze more out of his server. As always we’ve been using perfmon to view the server’s performance counters and since we were investigating CPU spikes we were interested in the thread activity counters that the server exposed.
The various perfmon enabled example servers that ship with The Server Framework have always exposed counters that show the number of active and processing threads from various thread pools.
The new release of the licensed, high performance, I/O completion port, server framework includes lots of new example clients and servers; the framework now comes with 74 fully working example that showcase various aspects of the framework.
Since the UDP side of the framework has undergone a lot of work recently to support filtering and in preparation for the release of several reliable UDP protocols there are lots of new UDP server examples.
So far I’ve found Visual Studio 2010 quite a compelling upgrade from Visual Studio 2008 for native C++ development. Intellisense is better, the build experience seems smoother and faster, editing on a decent development box seems OK, the various profiling and concurrency tools look interesting and, well, it mostly works quite nicely.
It’s a pity that there are some rough edges. I’ve been seeing crashes when I update project and solution files whilst it has them open (a common thing to do if you’re working with source control).
