Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: "Stephen J. Butler" <email@hidden>
- Date: Wed, 24 Jun 2009 22:25:24 -0500
On Wed, Jun 24, 2009 at 8:19 PM, Jeff Laing<email@hidden> wrote:
> Unless you peer into the implementation details of your superclasses, you should assume that all classes may have a finalizer. Unless you don't care about every last little piece of performance.
I don't understand your point. If the superclass has a finalizer and
implements IDisposable, then you don't need to "peer into the
implementation details". Just see if it implements IDisposable and
handle appropriately.
On the other hand, if it doesn't implement IDisposable yet has a
finalizer, then there's nothing you can do about it. You can't
implement your own Dispose and call GC.SuppressFinalize(). You're just
stuck with whatever you have. So why worry about it at all?
Anyway, this discussion has gone way off topic, unless we're using
CocoaSharp :) Objective-C objects have different finalize semantics
than C# objects, which have different semantics than Java objects.
> In my day app, we regularly cache hundreds of thousands of objects from a persistent (relational) store and it is absolutely critical to us that the instant that those objects aren't required, they give their memory back - that's how we can run in a machine with only(?) 1 gig of ram. So I'm one of those people I mentioned earlier that really really cares that cleanup happens as soon as possible, not when the fourth or fifth pass through the queue is done.
Can you use weak, zeroing references for the cache? I mean, CoreData
theoretically caches large numbers of objects, yet it still works
under GC.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden