Re: Re[2]: NSTableView and memory management problem.
Re: Re[2]: NSTableView and memory management problem.
- Subject: Re: Re[2]: NSTableView and memory management problem.
- From: Steven Kramer <email@hidden>
- Date: Mon, 28 Mar 2005 22:21:57 +0200
Of course those operations require some time (it's clearly seen during
the debug session) - seconds. After that application seems to be
frozen (It does not consume CPU time (very little)) for 10-20 seconds.
When I debug this stage in "step" mode I see that the code is calling
"NSPopAutoreleasePool" again. So, there are two moments when very time
consuming NSPopAutoreleasePool are called - when I leave "timer_action"
function and when the modal panel is going to be closed.
I think this behaivior generally is correct, but in my particular case
these
calls (NSPopAutoreleasePool) do only harm - they consume very valuable
time, although all resources have been released manually.
May be I misunderstand something but it would be good to avoid these
calls - there is no real need, because no one object is supposed to be
autoreleased.
Sorry for such a long post, simply try to explain the situation is
detail. Any suggestions are welcome!
Objects will often retain+autorelease in a getter, or autorelease in a
dealloc, an object that they own. This has nothing to do with your
(non)use of autorelease, it's just implementation details of the class
you are using. Maybe NSArray autoreleases its objects on dealloc, maybe
not. Maybe it's NSCell. I don't know, it's probably not documented and
you generally shouldn't care. In your specific case, this is bad news
but if you want to do something about it you'll have to do some serious
tweaking, I'm afraid... Check the state of the autoreleasepool right
before the big Pop to see what's in there and you might be able to
customize the behavior of the framework classes concerned.
Regards,
Steven Kramer
--
email@hidden
http://sprintteam.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden