GC with C# and C++ in same solution

Question

I have a solution consisting of a number of C# projects. It was written in C# to get it operational quickly. Garbage collections are starting to become an issue—we are seeing some 100 ms delays that we'd like to avoid.

One thought was to re-write it in C++, project by project. But if you combine C# with unmanaged C++, will the threads in the C++ projects also be frozen by garbage collections?

UPDATE

Thanks for your replies. This is, in fact, an app where 100 ms might be significant. It was probably a poor decision to build it in C#, but it was essential that it be up and running quickly at the time.

Right now, we're using Windows' Multimedia Timers to fire an event every 5 ms. We do see some 100+ ms gaps, and we've confirmed by checking the GC counters that these always occur during a collection. Optimization is on; built in Release mode.

Answer 1

I work as a .NET developer at a trading firm where, like you, we care about 100 ms delays. Garbage collection can indeed become a significant issue when dependable minimal latency is required.

That said, I don't think migrating to C++ is going to be a smart move, mainly due to how time consuming it would be. Garbage collection occurs after a certain amount of memory has been allocated on the heap over time. You can substantially mitigate this issue by minimizing the amount of heap allocation your code creates.

I'd recommend trying to spot methods in your application that are responsible for significant amounts of allocation. Anywhere objects are constructed is going to be a candidate for modification. A classic approach to fighting garbage collection is utilizing resource pools: instead of creating a new object every time a method is called, maintain a pool of already-constructed objects, borrowing from the pool on every method call and returning the object to the pool once the method has completed.

Another no-brainer involves hunting down any ArrayList, HashTable, or similar non-generic collections in your code that box/unbox value types, leading to totally unnecessary heap allocation. Replace these with List<T>, Dictionary<TKey, TValue>, and so on wherever possible (here I am specifically referring to collections of value types such as int, double, long, etc.). Likewise, look out for any methods you may be calling which box value type arguments (or return boxed value types).

These are just a couple of relatively small steps you can take to reducing your garbage collection count, but they can make a big difference. With enough effort it can even be possible to completely (or at least nearly) eliminate all generation 2 garbage collections during the continuous operations phase (everything except for startup and shutdown) of your application. And I think you'll find that generation 2 collections are the real heavy-hitters.

Here's a paper outlining one company's efforts to minimize latency in a .NET application through resource pooling, in addition to a couple of other methods, with great success:

Rapid Addition leverages Microsoft .NET 3.5 Framework to build ultra-low latency FIX and FAST processing

So to reiterate: I would strongly recommend investigating ways to modify your code so as to cut down on garbage collection over converting to an entirely different language.