Isolator Performance Fix – Support Story

Don’t know about you, but every time I hear about performance degradation issues, I start to tremble. Not from joy. These things are not easy to debug and solve, and sometimes they don’t even reproduce.

Not this time. This time I managed to reproduce it in a few minutes and 2 lines of code. Thanks to a report here-I’d like to compliment Tim Berston, since his portrayal of the problem was very accurate, which resulted in a quick repro.

The problem happens in test suites that do lots (and I mean lots) of interface mocking. As you probably know, Isolator can be used to mock interfaces and abstract classes, using MockObject. Technically, Isolator creates a new type under the covers that implements the interface. This type has to sit somewhere in memory, so it is stored in a dynamically created assembly. Problem was that every time we called MockObject, a new assembly and type were created. And if you are mocking a lot of interfaces, it comes down to a lot of memory. Which gets to paging and even to Out Of Memory exception.

Like I said, once it was reproduced, The way to the solution was quite easy. Now interfaces are cached and stored in a single assembly during a run. Which cut down Wendy’s build time from 40 minutes(!) back to 8 minutes.

I like stories with happy ends. Working at Typemock allows me to get the feedback from customers very quickly on my work. This is gratifying (much more when fixes actually work…). I wrote before (and I will again) about the value ongoing support work brings to the development team. This case reaffirms it.

This fix will be part of the next Isolator release. If, however, you’re doing serious interface mocking, you might want to leave a note here, so we can send you a patch. Funny thing – this was in the code for a while, and in one week we get 3 different calls. On the other hand, it’s one solution for 3 customers. Can’t beat that.

TOP