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: Fri, 8 Dec 2006 08:56:05 +0100
Melissa,
After I sent the email, I thought about the NSUndoManager. I did try
2 different things:
// where the MOC is allocated
[[self managedObjectContext] setUndoManager:nil];
and I've tried [[[self managedObjectContext] undoManager]
disableUndoRegistration] too
but it doesn't help!
is disableUndoRegistration (at the very beginning of course) the
right way to "clear the undo stack"?
Anyway, my objects are still not dealloced after that...
Note that i tried under Leopard... just in case and the behavior is
the same.
Thanks
On 8 déc. 06, at 00:14, Melissa Turner wrote:
The problem is that the undo manager has a retain on the inserted
object. If you clear the undo stack, the MO should be released.
The goal of using refreshObject:mergeChanges: to turn objects into
faults is to break retain cycles inside the object graph so that
individual objects inside the graph will be released when
everything outside the graph that is retaining them releases them.
But first, everything outside the graph retaining them has to
release them.
+Melissa
On Dec 7, 2006, at 05:56, Aurélien Hugelé wrote:
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