Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: email@hidden
- Date: Tue, 19 May 2015 11:46:11 +0900
I'm going to butt in here and say that if you've got so many objects that it is causing memory pressure, you really just need to reevaluate and blow up your model.
Consider using a database or Core Data.
Tracking and storing large relational sets of data is exactly what those things do well.
That might just reduce the effort and fragility and complexity tremendously.
And it will let you use tried and tested code and focus instead on a schema.
Sent from my iPhone
> On 2015/05/19, at 9:48, Roland King <email@hidden> wrote:
>
>
>> On 18 May 2015, at 14:59, Britt Durbrow <email@hidden> wrote:
>>
>> Unfortunately I don’t think NSCache will work for me in this situation.
>>
>> The objects in the pool have a UUID that is used to maintain the graph structure’s coherency when it’s partially or entirely on disk. In RAM, there can be only one object per UUID; but if something points to an object that the cache is trying to evict, that object won’t get deallocated from RAM (because it’s retain count isn’t zero post eviction) but the object pool controller won’t know about it still being in RAM (as it’s no longer in the cache), and when the controller attempts to reload it from disk; there would be multiple in-memory objects purporting to have the same UUID. As is oft claimed about these sorts of situations, hilarity would ensue…
>>
>> Keeping multiple pointers to the same object strikes be as ugly also… perhaps more ugly than just looking at retainCount: it does more or less the same thing, but with a greater footprint (memory, CPU, and battery).
>>
>> My understanding of retainCount is that it’s basically considered “taboo” because trying to use it without knowing exactly what you are doing tends to lead to pitfalls, and most people looking at it tend to think it means something that it doesn't. 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!
>>
>> :-)
>
> If I was doing this I’d have an NSMapTable with strong keys (UUID) to weak objects (the objects). Put new objects in the table against their UUIDs, when nothing else references them they get destroyed automagically, When you need an object, look it up by UUID, if it’s there it’s there else create it. If it’s also desirable to have objects stay cached until such time as there’s memory pressure and then release them, I would also then put each created object in a set/array/whatever called TempCache which gives it another strong reference. When the OS rings the doorbell and complains about memory, I throw the cache set away, let the map table destroy stuff now not-referenced, and then put all the remaining objects in the map table back in a new set/array/whatever to start caching again.
>
> That requires very little coding, works under ARC and gives me the choice of making the cache smarter without too much effort, ie I could make it an LRU cache referencing the last 1000 objects used, or a full LRU cache where, when I get a memory warning I throw away 100 objects from the end until memory usage has reached a ‘reasonable’ state.
>
> Perhaps I missed something germane in the discussion about why a simple scheme like that doesn’t fulfil all requirements.
> _______________________________________________
>
> 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
_______________________________________________
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