No the garbage collector is certainly less overhead than manual heap
deallocation in most cases. Consider a loop where you might allocate and
deallocate memory say 100,000 times. The GC will likely defer any
deallocation until after that loop is complete, thus reducing the overhead
of unnecessary memory management during the loop itself.
There's nothing unreliable about the GC. In fact, you can *rely* on it
deallocating memory eventually, where-as if you forget about allocation
under a heap-managed program then it'll just be a dangling reference and
will become a memory leak.
The GC knows about the state of memory consumption in the process as a
whole, and can optimize its operations accordingly. It employs sophisticated
algorithms to determine which memory deallocations should have priority,
which can often save a signficant number clock-cycles in critical sections
of code.
You can find plenty on the web about how the GC works if you really have a
problem trusting it. In my experience (and I'm sure I share this with
others), it's certainly not a burden in any way, quite the opposite.
--
John Wood
EMail: first name, dot, last name, at priorganize.com
breathedotnet said:
C++ had a delete operator for every new one created. .Net says i would do
that job but why do we need some backend unreliable process to do it when u
cud have done it.
so many bugs that it ends up in u cleaning up the mess day and night.
