Thanks for the lengthy reply. I need to start studying GC's before I assume more things like that. :)<br><br><div class="gmail_quote">On Tue, Aug 10, 2010 at 3:11 AM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisprog@gmail.com">jmdavisprog@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Monday, August 09, 2010 17:07:28 Andrej Mitrovic wrote:<br>
> I don't have a lot of experience in this field, but my guess is people want<br>
> to help out the GC be more efficient in some regard.<br>
><br>
> "Hey, GC! I know you take the trash out every day, but I just want to let<br>
> you know that I've cleaned up my room and there's a whole bag o' dirt in<br>
> here ready to be thrown out that you should know about. See ya later!"<br>
><br>
> My assumption is that the programmer probably knows when and how he uses<br>
> memory more so than the GC itself. So my thinking is some kind of hybrid<br>
> approach would be a good choice between safety and performance here. But<br>
> correct me if I'm wrong, I'm walking in the dark really..<br>
<br>
</div>A GC is tuned with the idea that it will run periodically and free memory which<br>
is freeable at that point rather than frequently freeing it at the programmer's<br>
request like happens with manually managed memory. And since freeing memory can<br>
be expensive, it can be argued that it's actually more efficient to just let the<br>
memory not be freed until the garbage collector does its thing whenever that is.<br>
I've heard that there have been papers showing that that's more efficient, but I<br>
haven't read them. The issue is if the time that the garbage collector decides<br>
to run is when you're trying to do something time or resource-sensitive, and the<br>
garbage collector picks a bad time to run. But that's generally a fact of life<br>
with garbage collectors, and if it's an efficient garbage collector, then<br>
hopefully the hit is minimal.<br>
<br>
Also, it's not like the garbage collector is likely to be really freeing your<br>
memory anyway, unless it decides that it just has way too much allocated. So,<br>
telling it that you want it to free something really is only getting the<br>
destructor called for you, which likely only matters if you have another<br>
resource of some kind (like file handles or something) which you need freed. And<br>
if that's what you need, you could just as easily call a function on the class<br>
to free that up as go and completely destroy it. The one thing that I can think<br>
of that clear() might get for you otherwise is helping the GC know that it any<br>
other references that that class holds aren't needed anymore, but if you no<br>
longer have any references to the object in question, the GC should already have<br>
that information.<br>
<br>
Really, in the general case, it's going to be most efficient to let the GC do what<br>
it does. If it's well-written, it should do it efficiently. Trying to tell it that<br>
you know best is not likely to work well (in the general case, at least). If you<br>
really want to be freeing things as soon as you're done with them, you need to<br>
do manually memory management. Besides' s soon as you're keeping track of when<br>
it would be okay to clear() an object, that's pretty much what you're doing<br>
anyway.<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
</font></blockquote></div><br>