If it's a local variable inside the method, setting it to null when you're
finished with it usually doesn't help.

This is because if a GC happens in the middle of the function, the JIT can
tell if you are no longer using the object, even if its reference is still
in scope, and hence allow the GC to collect the object. I think the only
time you could outsmart the jit might be a situation like this:

SomeClass SomeObj = new SomeClass();

for (int i = 0; i < 10; i++)
{
   if (i < 5)
   {
       SomeObj.DoSomething();
       ...
   }
   else
   {
       ...
   }
}

In this case, if a GC happens during the loop, at, say i = 6, I doubt the
JIT will be able to tell that you won't be using the object any more. So
nulling it out may cause the object to be collected slightly earlier.
However, you should realise that all this hinges on when the GC collects. If
it collects after the loop, then you won't need to null out the reference.
So this code only helps if it's quite likely there will be a GC during the
loop, but after you are finished with the object.

Gen 0 and 1 must be growing in some way, because objects need to pass there
on their way through to Gen 2. How frequent are collections on Gen 0, Gen 1
and Gen 2? I think you should give the CLR Profiler a try, as Eric
suggested. You can see what types of objects are taking up all the space in
Gen 2, and work out how to reduce the number of allocations of those
objects.

I don't know how complex your tracer is, but I found from the nature of mine
that a lot of allocations are locals only, hence they die quickly. Most of
the objects that my tracer uses are very temporary - just colours, vectors,
etc. They're used for a couple of calculations, then they're useless. So
they should always die in gen 0. If you're looking to reduce the number of
allocations, you might pool simple types like vectors, and hence they will
end up in gen 2, but as long as the pool size is small, gen 2 should not
grow by much...

Niall