Re: NSMutableArray + NSEnumerator = No Memory
Re: NSMutableArray + NSEnumerator = No Memory
- Subject: Re: NSMutableArray + NSEnumerator = No Memory
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 22 Sep 2007 12:05:06 -0700
On Sep 22, 2007, at 11:36 AM, James Bucanek wrote:
1 - Use objectAtIndex: to iterate through the array.
2 - Create an auto release pool and discard the NSEnumerator during
every search.
This is likely a good idea to do regardless of the rest of the problem
as it is likely that you are causing, directly or indirectly,
temporary objects to be created. Dumping 'em every so often when
doing lots of looping is generally a good idea.
3 - Abandon NSArray and roll my own collection.
I'm leaning towards (1) because it minimizes the code change and
shouldn't incur too much additional overhead. (2) will keep me from
running out of memory, but doesn't guarantee that other calls to
objectEnumerator won't make gratuitous copies of the array.
(3) is ultimately the best solution, as I can increase the speed and
reduce the memory footprint of the collection considerably by
dropping NSArray altogether. But that's a lot of coding and I'd
rather not make any radical changes in my application at the moment.
Are you sure that it is actually making a copy of the objects and
that, given the number of iterations, you are simply exhausting memory
by filling up the autorelease pool with temporary objects that are
created as a part of your matching algorithm?
I would be surprised if the implementation of NSArray has any notion
of a previously allocated NSEnumerator still being active on the
array. Mutation of the underlying array is always unsafe during
iteration and, thus, doing so is unlikely to add any safety during
execution.
(3) sounds fairly futile. NSArray and friends have been quite highly
optimized over time. Certainly, there are likely more optimizations
possible, but they are unlikely to be simple to implement. Unless
you have a highly specific usage pattern for which a non-general
algorithm will be a significant performance win, it is unlikely that
re-engineering that which already exists in the Foundation is going to
be much of a win.
I'm not saying it isn't possible that your own custom collection
wouldn't be a win, but it sounds like you still have some
investigation to do in regards to memory usage before going there.
b.bum
_______________________________________________
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