Re: NSAutoreleasePool: how does it really work?
Re: NSAutoreleasePool: how does it really work?
- Subject: Re: NSAutoreleasePool: how does it really work?
- From: Christian Longshore Claiborn <email@hidden>
- Date: Tue, 18 Mar 2003 13:27:26 -0800
I think you're running into a conceptual problem: the assumption that
your allocations and deallocations are atomically linked to the actual
memory allocation that the operating system is performing for your
program. Because C is so close to assembly language, we tend to think
of each call to malloc() and free() (or even [alloc] and [dealloc]) as
affecting the amount of heap that the process is currently allocated,
but this isn't necessarily true. There are a number of variables
involved: how much contiguous empty space there is in the heap, the way
that malloc determines the number of pages needed, whether the
implementation uses sbrk() or mmap(), etc.
There is, basically, no guarantee that when you finally [dealloc] an
object, the application reduces its memory footprint. This is often
actually a good thing, since you wouldn't want to release memory just
to allocate it again right away.
So, what can you do? Relax.
Since you're using a higher-level interface, other people (people who
have spent a lot of time profiling different allocation strategies) are
worrying about how much memory to take from the operating system. The
downside is that you're occasionally going to take more than you
actually need. The upside is that your responsibility is only to
manage the retain counts of your objects and let the runtime do the
rest.
What you need to watch for is growth; if your routine allocates 8
megabytes every time it runs, then you've got a memory leak. If after
exercising each portion of your program, your memory footprint is
stable, then you're doing fine.
Christian
On Tuesday, March 18, 2003, at 09:14 am, Lorenzo Puleo wrote:
Ok Bill, thank you,
but please what can I do now? How should I modify my code in order to
use
the memory properly? I am trying all the time, unsuccessfully. The unix
"top" command tells me that Rsize and Free Mem never come back to the
initial values.
Should I still
Best Regards
--
Lorenzo Puleo
email: email@hidden
compact the heap like in Carbon?
Best Regards
--
Lorenzo Puleo
email: email@hidden
From: Bill Bumgarner <email@hidden>
Date: Tue, 18 Mar 2003 11:55:55 -0500
To: email@hidden
Cc: Lorenzo Puleo <email@hidden>, Phill Kelley
<email@hidden>
Subject: Re: NSAutoreleasePool: how does it really work?
On Tuesday, Mar 18, 2003, at 11:39 US/Eastern,
email@hidden wrote:
... analysis deleted ...
- (IBAction)MyLoop:(id)sender
{
int i;
xArray = [NSMutableArray array];
for ( i = 0; i < 500000; i++ )
{
NSAutoreleasePool *myPool = [[NSAutoreleasePool alloc]
init];
[xArray addObject:[NSString stringWithFormat: @"Don't leak,
step
%d", i]];
[myPool release];
}
[xArray removeAllObjects];
return;
}
The release pool in the above code doesn't actually do anything
(except
slowing down the code)!
The @"..." format string is statically allocated; there should be
only
one.
The string instance produced by -stringWithFormat: is autoreleased
into
myPool, by you shove it into an array inside of myPool's scope. This
ensures that the string is persisted beyond the call to -release on
myPool.
If you were to remove the allocation of myPool, you will likely see a
reduction in the memory usage because of fewer object
creation/deletion
events to potentially fragment the heap.
b.bum
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.