Cor,
I agree with you to avoid global variables. Globals tend to make code far
more difficult to debug.
According to MS, there are three starting points for the .NET GC mark
phase - the global variable pool, the runtime stack (for each thread), and
an additional set of "dirty" object references. Putting all your variables
in the global pool simply increases the size of the global pool and forces
the GC to spend more time in this pool. Local variables, on the other hand,
go on the stack. If you are deeply nested, it may take longer to process
the stack, but this is where the "dirty" object reference optimization in
..NET comes in. .NET's GC is smart enough to not do the mark pass on objects
that survived the previous GC pass unless your code writes to those objects.
By keeping your variables local, your code is much less likely to update
variables that survived previous GC passes.
Sharrukin,
If you are really concerned with the performance of your code to the extent
that you need to be able to predict how long a function will take to
execute, Windows isn't the answer. You need a real time operating system.
If you simply want to make sure there aren't long, user noticable, pauses in
your program due to GC activities, use local variables. Microsoft
recommends against intermediate lifetime objects as these are the ones that
will defeat the "dirty" object reference optimizations. Short lived objects
will get reclaimed on their next pass. Program lifetime lived objects will
never get reclaimed, even if they aren't being used. Use globals only if
required. Use locals for everything else. This will make your code a lot
easier to understand and debug. The other optimization that Microsoft
recommends is to implements your objects so that they don't need to
implement the IDisposable interface, as this prevents an object from being
reclaimed on the first pass. The GC puts these objects on a Finalize list
that then gets processed by a single thread after the GC completes it's pass
and restarts application threads. A large number of objects on the Finalize
list can lead to a lot of "dirty" object references being generated.
Mike Ober.
