> On May 19, 2015, at 7:20 AM, Steve Christensen <puns...@mac.com> wrote: > > I just finished catching up on the discussion and keep coming back to the > fragile nature of relying on retainCount. For now you do, indeed, have the > option to vaporize your toes; later you may not have access to a ray gun if > Apple decides that it's in the best interests of all concerned that they > retain their toes, not their objects. >
Restating a previous concern of mine: > However, it’s not actually something that’s likely to get deprecated; and by > paying very careful attention to the rules, it should be OK to use in this > very narrow circumstance? > > If this is wrong - please (hopefully someone from Apple) correct me! Yes, I am a bit concerned that it could become deprecated. I suppose that I could just override retain and release in that case; and track the retain count myself; although I seriously doubt that that functionality will be deprecated/removed as there’s too much oddball stuff that depends on it… but uggghhhh… that’s nasty. To borrow a phrase from a lolcat, “DO! NOT! WANT!” :-) > I don't know what your app architecture looks like, but was wondering if you > could build in a supportable method of managing what's in the cache without > having to do other than a few localized changes. > > One thought I had was to base all your cacheable objects on a class whose > sole function is to notify the cache when the last reference goes away, i.e., > when dealloc is called. If the cache kept track of all cached objects using a > NSMapTable with weak references then the cache itself wouldn't affect the > retain count, so you'd never have to be looking at that. Reads from and > writes to the NSMapTable would need to be protected for consistency. > > Does this sound like it could work? Um… that’s just a weak link? And the only way for an instance to know that it’s got a reference to it outstanding is to override retain and release? *************************************************************************************************************************************************************************** > On May 19, 2015, at 2:07 AM, dangerwillrobinsondan...@gmail.com wrote: > But I'm curious if Instruments tells you anything about where to optimize. Yeah, I’m gonna have to do some profiling to see if my intuitive suspicions are anywhere near accurate… (premature optimization being the hazard that it is) > A model that's 12 years old should surely have had memory issues on 12 year > old computers as much as on a modern iOS device. Document sizes were smaller then… and the engine has been adapted to new projects since it started out in life. > > If there's some kind of relationship to a virtual machine there must be a way > to give it virtual limits. It’s not a virtual machine that I was referring to (like the Java virtual machine, or like VirtualBox) but the operating system’s virtual memory support, aka swapping-to-disk. The engine was originally designed to just keep all the objects in RAM, and if physical RAM ran out, the OS would page out less used objects to swap space. iOS does not do that; which is why I need to manage the memory myself. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
