« May 2010 | July 2010 Archives | August 2010 »
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...…

STLPORT 5.2.1 AND VS2010 AND X64

| 7 Comments
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. The changes are similar to those required for getting VS2008 to work with STLPort 5.1.5 (and 5.2.1) see here for details of those.…
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. The tests were written for the pretty scalable timer queue implementation…
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. One of the things that struck me about the code when I was looking at it during my profiling runs for my client is that when using the CThreadedCallbackTimerQueue in…

More thoughts on Big C

| 2 Comments
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). This is simple enough and means that C(1) is no contention on a single lock as there's only one…
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.7 days with a theoretical granularity of 1ms. It achieves this by using a balanced search tree to…
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…

Practical Testing: 25 - Nothing is free

| 0 Comments
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. As soon as I started to look at making some of the failing tests pass I realised that having a heap of failing tests…

Amusing bug in GetTempPath()

| 0 Comments
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…
Previously on "Practical Testing"... To deal with some specific usage scenarios of a piece of general purpose code 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 timer wheel trades space for speed and so far the development has gone well as I've been able to use the tests that I had already developed for the previous implementations to guide the new development. By the end of last time we'd got to the point where we had four functions left to implement...…

Tool lag

| 6 Comments
One of the problems of having a collection of tools that interoperate is that there's often a lag between when a tool will interoperate with the latest version of another tool. I'm hardly a bleeding-edge tool junky, I wait until RTM before I start using the latest Visual Studio on a daily basis, and in the case of VC 6 I stuck with it (as did most of my clients) until VS2005 came out and actually improved life for unmanaged C++ development... However, it seems that some tools take a long long time to catch up with Visual Studio. Take…
I've recently been adjusting my CLR hosting code as a client wanted to be able to host the .Net 4.0 runtime. Previously they were hosting the 2.0 runtime and, as I mentioned a while back, the hosting API has changed with 4.0. Switching to hosting 4.0 was easy enough but being able to fall back to hosting 2.0 on a machine where 4.0 wasn't installed is slightly more complex. It's reasonably obvious (you need to make sure that you call GetProcAddress() to bind to CLRCreateInstance() rather than linking to it at build time), but Brad Wilson has a nice list…
I'm working on some prototype code right now to improve the "deployment characteristics" of a socket server that I wrote for a client which uses CLR hosting to provide multiple managed applications within a single unmanaged host. The client wants to be able to start, stop and restart individual managed applications within the server so that during development or when a managed application is updated they don't need to restart the whole unmanaged server process to use a new version of a managed application. This is all quite easy to do using separate application domains for each managed "application" within…
« May 2010 | July 2010 Archives | August 2010 »

About this Archive

This page is an archive of entries from July 2010 listed from newest to oldest.

May 2010 is the previous archive.

August 2010 is the next archive.

I usually write about C++ development on Windows platforms, but I often ramble on about other less technical stuff...

Find recent content on the main index or look in the archives to find all content.

I have other blogs...

Subscribe to feed The Server Framework - high performance server development
Subscribe to feed Lock Explorer - deadlock detection and multi-threaded performance tools
Subscribe to feed l'Hexapod - embedded electronics and robotics
Subscribe to feed MegèveSki - skiing