Re: Core Data, using refreshObject:mergeChanges: to trim a portion of my object graph and regain memory... PLEASE HELP!!!!!!!
Re: Core Data, using refreshObject:mergeChanges: to trim a portion of my object graph and regain memory... PLEASE HELP!!!!!!!
- Subject: Re: Core Data, using refreshObject:mergeChanges: to trim a portion of my object graph and regain memory... PLEASE HELP!!!!!!!
- From: Aurélien Hugelé <email@hidden>
- Date: Thu, 7 Dec 2006 14:56:31 +0100
As i was trying to find the problem, i made a very simple prototype
(the simplest core data app ever) that you can download at http://
developer.gumitech.com/CoreDataMemTester.zip
I'm pretty sure it is a Core Data memory management bug since no
NSManagedObject is deallocated
basically:
create a NSAutoreleasePool (or use the one created by the
NSApplication for you)
create a MOC
insert just one object (the simplest core data object ever) using
insertNewObjectForEntityForName:inManagedObjectContext:
save the context (because inserted/deleted/updated objects are
retained my the MOC)
release the pool if needed (it is indeed deallocated)
At this point the inserted object should have been deallocated since
nothing retains it. This is explained in the documentation (file:///
Developer/ADC Reference Library/documentation/Cocoa/Conceptual/
CoreData/Articles/cdMemory.html#//apple_ref/doc/uid/TP40001860)
Analysing the memory state with objectAlloc or even MallocDebug shows
that the inserted object is autoreleased, but has not been dealloced
(nor retained)
Can somebody explain this strange problem?
To dealloc the object, you have to reset the MOC... as if the MOC
retained the object (which should not be the case, it is explained
pretty well in the documentation). Note that retainsRegisteredObjects
returns NO...
Thanks
On 4 déc. 06, at 12:46, Scott Stevenson wrote:
On Nov 30, 2006, at 2:44 AM, Aurélien Hugelé wrote:
But using top, Activity Monitor "Real Memory" column i can see
that this has no effect at all!
commenting this code produce the EXACT same amount of memory to be
consumed...
This is a bit outside of my area of expertise, but I looks like no
one else has responded so I'll do what I can.
The type of thing you see in Activity Monitor is not necessarily
the whole story. The kernel's behavior is -- from what I've seen --
more "fluid" than what you're expecting. It also doesn't tell you
how, exactly, your application is consuming memory. It might be
managed objects, it might be something else.
It's fine as a point of reference, but what you're looking at is so
far removed from the behavior of the managed object context that
you can't trust this source alone. In other words, your application
might already be doing the right thing without you knowing it.
You could loop through some set of the objects and check their
status by sending them -isFault and seeing what you get back.
You might also consider experimenting with this method on
NSManagedObjectContext:
-reset
Returns the receiver to its base state.
Discussion
All the receiver's managed objects are "forgotten." If you
use this method, you should ensure that you also discard
references to any managed objects fetched using the receiver,
since they will be invalid afterwards.
I believe it's non-destructive in the sense that it doesn't change
any data. It's as if the application had just started up before
anything is fetched.
- Scott_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
40gumitech.com
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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