Hello Nick,
First of all thank you for your reply! My method has been monitoring the mem
usage of the specified (and other calls) while in the debugger and trusting
guard malloc for memory leaks. With this the mem allocated by the said call
is instantly in the scale of
tenths of MBs for just one line of code (that runs slow on top of all) - the
allObjects call. However I have to admit that
I have limited knowledge on using the performance tools, especially because
as far as i know they work outside the debugger.
So I will have to study and try your proposal in any case - Instuments and
its Leaks look really cool :) ; I find it almost compulsory knowledge and
feel a real noob to have discarded it so far. Any hints for me or whoever
might be reading this are welcome.
Thanks again,
Vas.
On Fri, May 21, 2010 at 6:37 AM, Nick Zitzmann n...@chronosnet.com wrote:
On May 19, 2010, at 5:36 AM, Vassilis Pantazis wrote:
Hello,
I have in my code the following statement:
NSDirectoryEnumerator* dirEnum;
NSArray* inDirContents;
dirEnum = [[NSFileManager defaultManager] enumeratorAtPath:inPath]; //
inPath is a valid path
inDirContents = [dirEnum allObjects];
I have noticed that when the path contains many objects, a significant
amount of memory is allocated that is not released, neither when trying
to
explicitly release inDirContents, nor when using an autorelease pool.
Can someone explain to me why this happens please and how to solve it?
Have you tried using the object alloc instrument in Instruments? That will
show you what is really going on with your application's memory usage.
Nick Zitzmann
http://www.chronosnet.com/
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
