Previously on “Practical Testing”… I’ve been looking at the performance of the timer system that I developed and have built a more specialised and higher performance timer system which is more suitable for some high performance reliable UDP work that I’m doing. Whilst developing the new timer wheel I began to consider the thread contention issues that the timer system faced and came up with a notation for talking about contention (see here).
My previous rant about DevPartner Studio (and especially the BoundsChecker portion of it) resulted in several emails from guys on the development team and a call from product owner at MicroFocus. They pointed me towards the latest ‘web sync’ (service pack) which was released shortly after my rant, explained how the issues I’d noticed had made it through testing and why they existed and commiserated with me over the state of support.
Previously on “Practical Testing”… I’m writing a timer wheel which matches the interface used by my timer queue. This new implementation is designed for a particular usage scenario with the intention of trading space for speed and improving performance of some reliable UDP code. The last entry completed the development of the timer wheel. This time we fix a couple of the bugs that I’ve discovered since I started to integrate the code with the system that it was developed for.
The story so far, I’ve owned DevPartner Studio for several years and been on a support contract the whole time. The support situation went a bit flaky when Compuware sold the product to Micro Focus, I expect that either I’m simply not a big enough client for them to care or their post sales and support is just no where near as good as the Compuware offering. With Compuware I’d be contacted when new versions came out and I had a named sales contact that I could also use for questions, etc.
I’m still considering my options with regards to intrusive containers to replace the STL maps that I’m using in my timer queue implementation. I think I may be able to use the boost::intrusive sets in place of a true map in most of the situations that I need (I just have convince myself that a) it will work with all the compilers that I need to support, b) that adding a dependency to part of boost is a good idea for me and my clients and c) that even though my gut reaction on seeing the code is that it’s pointlessly clever and bound to be a bitch to debug it’s probably better than rolling my own).
Last time I explained how the managed side of my flexible hosting server architecture was structured. I dealt with the IDL required to generate the COM interfaces which were used to communicate between unmanaged code and managed code and detailed how the custom AppDomainManager object allowed me to load and execute managed code in such a way that it was easy to update the managed applications whilst the server was running.
Here’s a useful matrix which shows when each version of Visual Studio will become unsupported by Microsoft. I’m posting the link here as I’m sure I’ll not be able to find it the next time I need it…
Previously on “Practical Testing”… I’m writing a timer wheel which matches the interface used by my timer queue. This new implementation is designed for a particular usage scenario with the intention of trading space for speed and improving performance of some reliable UDP code.
Over the last four entries I’ve implemented various parts of the timer wheel and adjusted the test code so that I could reuse the tests that I already had for the other implementations with my timer wheel.
Rather than immediately dive into the fun of writing my own invasive alternative for std::map I decided to take a look at what has been done before, as expected boost contains something that might work in the shape of the “intrusive containers library”.
Of course, being part of boost I first have to work out exactly how much more of boost it will require me to depend on and then I have to work out how I can use it to replace my current std::map usage.
As I mentioned a while ago, I have some code which needs to perform better than it currently does and one of the areas that could be improved upon is the amount of contention for the heap that’s occurring. The fact that I’m using an STL map for my collection means that the class has a ‘big C’ contention value of C(n threads using the heap) rather than C(n threads using the object).
