Question

Here’s an interesting article that I found on the web.

It talks about how this firm is able to parse a huge amount of financial data in a managed environment, essentially by object reuse and avoiding immutables such as string. They then go on and show that their program doesn’t do any GC during the continuous operation phase.

This is pretty impressive, and I’d like to know if anyone else here has some more detailed guidelines as to how to do this. For one, I’m wondering how the heck you can avoid using string, when blatently some of the data inside the messages are strings, and whatever client application is looking at the messages will want to be passed those strings? Also, what do you allocate in the startup phase? How will you know it’s enough? Is it simple a matter of claiming a big chunk of memory and keeping a reference to it so that GC doesn’t kick in? What about whatever client application is using the messages? Does it also need to be written according to these stringent standards?

Also, would I need a special tool to look at the memory? I’ve been using SciTech memory profiler thus far.

Answer 1

I found the paper you linked to rather deficient:

• It assumes, and wants you to assume, that garbage collection is the ultimate latency killer. They have not explained why they think so, nor have they explained in what way their system is not basically a custom-made garbage collector in disguise.
• It talks about the amount of memory cleaned up in garbage collection, which is irrelevant: the time taken to garbage collect depends more on the number of objects, irrespective of their size.
• The table of “results” at the bottom provides no comparison to a system that uses .NET’s garbage collector.

Of course, this doesn’t mean they’re lying and it’s nothing to do with garbage collection, but it basically means that the paper is just trying to sound impressive without actually divulging anything useful that you could use to build your own.