TDPL: Manual invocation of destructor

[Andrej Mitrovic]

Thanks for the lengthy reply. I need to start studying GC's before I assume
more things like that. :)

On Tue, Aug 10, 2010 at 3:11 AM, Jonathan M Davis <jmdavisprog at gmail.com>wrote:

> On Monday, August 09, 2010 17:07:28 Andrej Mitrovic wrote:
> > I don't have a lot of experience in this field, but my guess is people
> want
> > to help out the GC be more efficient in some regard.
> >
> > "Hey, GC! I know you take the trash out every day, but I just want to let
> > you know that I've cleaned up my room and there's a whole bag o' dirt in
> > here ready to be thrown out that you should know about. See ya later!"
> >
> > My assumption is that the programmer probably knows when and how he uses
> > memory more so than the GC itself. So my thinking is some kind of hybrid
> > approach would be a good choice between safety and performance here. But
> > correct me if I'm wrong, I'm walking in the dark really..
>
> A GC is tuned with the idea that it will run periodically and free memory
> which
> is freeable at that point rather than frequently freeing it at the
> programmer's
> request like happens with manually managed memory. And since freeing memory
> can
> be expensive, it can be argued that it's actually more efficient to just
> let the
> memory not be freed until the garbage collector does its thing whenever
> that is.
> I've heard that there have been papers showing that that's more efficient,
> but I
> haven't read them. The issue is if the time that the garbage collector
> decides
> to run is when you're trying to do something time or resource-sensitive,
> and the
> garbage collector picks a bad time to run. But that's generally a fact of
> life
> with garbage collectors, and if it's an efficient garbage collector, then
> hopefully the hit is minimal.
>
> Also, it's not like the garbage collector is likely to be really freeing
> your
> memory anyway, unless it decides that it just has way too much allocated.
> So,
> telling it that you want it to free something really is only getting the
> destructor called for you, which likely only matters if you have another
> resource of some kind (like file handles or something) which you need
> freed. And
> if that's what you need, you could just as easily call a function on the
> class
> to free that up as go and completely destroy it. The one thing that I can
> think
> of that clear() might get for you otherwise is helping the GC know that it
> any
> other references that that class holds aren't needed anymore, but if you no
> longer have any references to the object in question, the GC should already
> have
> that information.
>
> Really, in the general case, it's going to be most efficient to let the GC
> do what
> it does. If it's well-written, it should do it efficiently. Trying to tell
> it that
> you know best is not likely to work well (in the general case, at least).
> If you
> really want to be freeing things as soon as you're done with them, you need
> to
> do manually memory management. Besides' s soon as you're keeping track of
> when
> it would be okay to clear() an object, that's pretty much what you're doing
> anyway.
>
> - Jonathan M Davis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100810/4efad609/attachment-0001.html>