• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSMutableArray + NSEnumerator = No Memory
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: NSMutableArray + NSEnumerator = No Memory
      • From: James Bucanek <email@hidden>
References: 
 >NSMutableArray + NSEnumerator = No Memory (From: James Bucanek <email@hidden>)

  • Prev by Date: Re: MySQL with Cocoa
  • Next by Date: Re: NSMutableArray + NSEnumerator = No Memory
  • Previous by thread: NSMutableArray + NSEnumerator = No Memory
  • Next by thread: Re: NSMutableArray + NSEnumerator = No Memory
  • Index(es):
    • Date
    • Thread