OOP Programming in VB.NET

  • Thread starter Thread starter Sharrukin Amiri
  • Start date Start date
Sharrukin,

I answered you in the language vb newsgroup with this message.

http://groups-beta.google.com/group/microsoft.public.dotnet.languages.vb/msg/cd6d8fdab445be8c?hl=en

Sadly enough there was somebody who told that my advice, not to set
everything global, was wrong. His reason was that the GC took an
unpredictable time to clean up and therefore the memory would not direct be
released. His message could be read, that he suggested that the time that
the GC would do this, could be after a very long time and that it therefore
is better to set everything global.

There were no comments on his message beside from me. Therefore when
somebody sees this and will give an second opinion on that, than I will be
glad.

In addition, to make my message more clear. Don't bother now about OOP
programming in VBNet. You cannot do it without that. Especially not because
I have looked to your code from begin to end and all ingredients are there,
which makes me sure that you will use that very soon after your start.

I hope this helps,

Cor
 
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.
 
Back
Top