• 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: Running out of memory with Core Data
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Running out of memory with Core Data


  • Subject: Re: Running out of memory with Core Data
  • From: "Ian G. Gillespie" <email@hidden>
  • Date: Tue, 26 Jul 2005 10:23:57 -0400

I added autorelease pools and it no longer runs out of memory. Thanks for the help.

Unfortunately, it still remains TERRIBLY slow. I used Shark but it seems that the calls that take the most time are private methods like _NSGetUsingKeyValueGetter and such. To import 10 accounts with 100 to 2000 transactions each takes several minutes.

In general if you end up processing large sets of data within a single function in Objective-C it's a good idea to regularly flush the autorelease pool since otherwise the memory fills up with lots of unreleased data and you can find yourself running out of room even though the memory doesn't contain anything of importance any more.


...


For the record, what *is* a good practice for this approach? Every nth loop through, flush the pool and start again, doing a final flush when exiting the loop?



I think it's highly dependent on the application as to exactly what the best way to do this is. If the body of the loop is large it might make sense to flush every time around. On the other hand I've had code which I know will autorelease a small handful of objects on each turn of the loop so I've made my code flush the pool every 1,000 turns and it worked well. On a couple of occasions I've had new code running out of memory so I've added a flush of the pool around some inner loop which has successfully proved that the autorelease was the source of the problem and then backed off to flush less frequently. I wrote some code similar to the following which proved useful:


#import <objc/objc-class.h>
@interface NvSAutoreleasePool : NSAutoreleasePool {
    long long raw_data_volume;
    long long raw_object_count;
}
- (long long) volume;
- (long long) count;
@end
@implementation NvSAutoreleasePool
- (void)addObject:(id)anObject {
    raw_object_count++;
    raw_data_volume += [anObject class]->instance_size;
    [super addObject: anObject];
}
- (long long) volume { return raw_data_volume; }
- (long long) count { return raw_object_count; }
@end

This lets you work out very approximately how much space is being used by objects in the autorelease pool, though it does nothing for double counting of multiple releases of the same object or any counting of data referenced from the auto-release object.

    Cheers,
        Nicko






_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Running out of memory with Core Data
      • From: Jed Soane <email@hidden>
    • Re: Running out of memory with Core Data
      • From: John Timmer <email@hidden>
  • Prev by Date: Re: NSMutableCopy Issue - New to Cocoa and Objective-C
  • Next by Date: Re: Cocoa from carbon - cursor tracking issues
  • Previous by thread: Re: Running out of memory with Core Data
  • Next by thread: Re: Running out of memory with Core Data
  • Index(es):
    • Date
    • Thread