Re: subpathsAtPath and memory usage
Re: subpathsAtPath and memory usage
- Subject: Re: subpathsAtPath and memory usage
- From: Peter Schols <email@hidden>
- Date: Thu, 23 Aug 2007 11:43:02 +0200
Clark,
Thanks a lot for your help and advice.
You are right: I have tested both with ObjectAlloc and 'leaks' and
all objects are neatly deallocated. No memory is leaked.
When looking at the system memory usage, it seems like all the memory
consumed is marked as 'inactive' indeed, so it's still there but no
longer being used and waiting to be reused.
The problem from an end user perspective still remains however: the
app slows down the entire system and causes many page ins/outs. Only
when I quit the app, the inactive memory size drops and the free
memory increases.
I guess my question becomes: how can I have the memory labeled as
free and not as cached (inactive), so that the system does not have
to use so much VM and remains more responsive? Or alternatively: how
can I 'convert' inactive memory to free memory without quitting my app?
Thanks again,
Peter
On 22 Aug 2007, at 23:43, Clark Cox wrote:
On 8/22/07, email@hidden <email@hidden> wrote:
Hi,
I have an NSFileManager / memory usage question. I have searched the
archives, the Cocoadev wiki and other sites but I can't seem to find
the answer.
In my app I'm using NSFileManager's subpathsAtPath call and this
works fine. However, when working with large directory structures
(e.g. my Home folder), this takes a lot of memory. This is probably
normal, but what puzzles me is that the memory is retained even when
the method has reached the end and all objects should have been
released. For example, for my Home folder the method below builds up
memory usage from about 30 MB to 650 MB. Even long after the method
below is completed, the memory usage remains at 650 MB.
This is what I'm doing:
- (IBAction)testMemory:(id)sender;
{
// NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]
init];
NSArray *children = [[NSFileManager defaultManager]
subpathsAtPath:@"/Users/myUserName/"];
// [pool release];
NSLog(@"Done!");
}
As can be seen from the code above, I even tried to create and
release my own NSAutoreleasePool but this has no effect. The memory
for my app builds up to 650 MB after this call and remains at that
level, long after everything should have been (auto)released. I tried
the same thing with the enumeratorAtPath approach but this has the
same effect.
Is there anything that can be done to avoid this. I guess the problem
might be that [NSFileManager defaultManager] does not release its
memory and since the object is a singleton, it stays alive as long as
my app lives.
Any suggestions on how to reclaim the memory that has been consumed
by this call would be much appreciated!
My first question would be: how are you measuring your memory usage?
Have you actually used a tool such as leaks or ObjectAlloc to see if
any objects are sticking around too long, or are you looking at the
figures displayed by top or Activity Monitor It is likely that the
objects have been properly deallocated, but that the memory is sitting
in a pool, waiting to be reused for future allocations.
Does running your test twice during one run of the app double the
memory used?
--
Clark S. Cox III
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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