> 1. If your objects use (scarce) resources that are not themselves > subject to GC (file handles, network connections, whatever), you'd be [snip] > 2. If you expect objects to be returned to the free memory pool "the > instant that those objects aren't required" then GC isn't going to > satisfy you. [snip] > However, in this case, it's the expectation that's unreasonable, not > GC behavior. You don't actually care that unreferenced objects die > instantly. You actually care than new objects can be created quickly.
Actually, I just care that they can be created at all. My situation is that "free memory is a scarce resource" for the class of applications that I'm working with, and there's no way that an IDisposable() can be bolted on to solve "memory" problems without completely replicating Release(). Its not reasonable to say "but virtual memory will solve that problem" because it just won't. My customers have terabytes of data any of which might be called into memory and cached there for performance reasons because we can't know when they are going to randomly access any of them, and the data is more complex than just a single row from a database table. We aren't using "hanging around in memory" as our caching mechanism, we hold things in LRU chains and we uncache the oldest ones first. A GC solution that doesn't immediately free the object when we release it means that we need to manually poke the GC machine to get the benefit of the uncache, whereas if we *know* that it will deallocate objects when we tell it to, we're fine. As has been pointed out, this isn't a .NET list, and I don't care strongly about this topic, except in as much as I was expressing an opinion about "the things that certain people with certain mindsets worry about and why GC upsets them". _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
