Re: NSAutorelease and memory usage (multithreads)
Re: NSAutorelease and memory usage (multithreads)
- Subject: Re: NSAutorelease and memory usage (multithreads)
- From: Chris Hanson <email@hidden>
- Date: Thu, 24 May 2007 00:27:56 -0700
On May 23, 2007, at 10:54 AM, Hell's KItchen Hell's KItchen wrote:
Unfotunatly I've two memory usage problems, according to OmniObject
Meter:
The first is with NSConcreteData istance read from server, and the
second is with a method called when saving to disk - it uses lots of
NSScanner istances.
1) This is the method that read from server:
http://paste.lisp.org/display/41661
2) While this is the method that istances lots of NSScanner istances:
http://paste.lisp.org/display/41660
In order to solve (2) I've tried to add NSAutorelease at starts/end of
this method. It simply does not work and the program crashes with
badaccess.
(I've corrected #2 above.)
The text in #2 indicates that you might think the autoreleased
NSScanner instance will be deallocated as soon as your method returns,
which is absolutely not the case. Cocoa Memory Management 101.
If adding an NSAutoreleasePool causes your code to crash, then your
code is incorrect.
Really, I think relying on OmniObjectMeter has caused you to have
incorrect expectations about Cocoa memory management and the memory
profile that your program should have. You keep bringing up
OmniObjectMeter in the context of various memory problems that you
identify as either leaks or excessive consumption, but it's not clear
that either is truly the case based on the code you post.
For example, your code in #1 does not create the NSData instances
you're complaining about. Some object whose class is NetSocket does.
The *only* thing the code in #1 truly knows about these NSData
instances is that *it* doesn't own them. Similarly, this code calls
some other code of your own like -_preFetchRawData: -- are you sure
that it's not creating any NSData instances that will persist beyond
your NSAutoreleasePool instances?
I strongly recommend reviewing the documents on memory management in
the monthly informational mailing, and thoroughly reviewing your code
to ensure that its use of Cocoa memory management is completely
correct before you start investigating its behavior with tools like
OmniObjectMeter. They can be very powerful, but sometimes powerful
tools misapplied can lead us astray.
Also, a general piece of coding advice: Lots of short (1-10 lines
long) methods are good, since they're easy to verify for correct
behavior. It's also very useful to only have a single non-exceptional
return from a method. Dong so makes it easier to verify correct
behavior by inspection, and it also makes it easier to do things like
add an NSAutoreleasePool in a method.
(This is because there's only a single boundary around which you'll
need to retain/autorelease any objects that should live beyond that
pool, e.g.
- (NSString *)sayHelloTo:(NSString *)name
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *s = [NSString stringWithFormat:@"Hello, %@", name];
[s retain];
[pool release];
[s autorelease];
return s;
}
The above is a contrived example, but the gist should be clear.)
-- Chris
_______________________________________________
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