• 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: Garbage collection, core data, and tight loops
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Garbage collection, core data, and tight loops


  • Subject: Re: Garbage collection, core data, and tight loops
  • From: "John R. Timmer" <email@hidden>
  • Date: Sun, 04 Nov 2007 00:06:24 -0400


On Nov 3, 2007, at 8:26 PM, Ben Trumbull wrote:

Okay, so for completeness, i thought i'd share the resolution of this
with the list, in case someone finds this thread in the future.

I set the app up to create small batches of ManagedObjects (several
hundred at a time) and added a small pause (0.01 sec.) between batches
via a delayed selector.

You shouldn't need a pause, and you should have good results with batches in the thousands.

Batches of about 350 just turned out to be what i wound up with when reading the input file a megabyte at a time. The pause just helped me avoid a recursive call and set me up for threading things.



Before creating any ManagedObjects, i cancelled undo registration.

Once a batch was created, i processed pending changes, saved, and
reset the managedObjectContext.
	incidentally, resetting appears to create a brand new undo manager
for the context, so i disabled each time; there was no need to re-
enable when done.

To disable the undo manager on NSManagedObjectContext, set it to nil. -reset does not recreate an undo manager.

Interesting. I disabled it using disableUndoRegistration, and then tried to re-enable it after resetting the managedObjectContext, and the app logged a complaint that suggested it had already been re- enabled.




Using an autorelease pool for each batch worked well, keeping memory
use extremely low.

Using garbage collection resulted in a significant memory gain, but
nowhere near bad enough to crash the program.  Oddly, the memory use
did not subside after the loop had finished.

How did you measure that ? 'heap' will provide more useful information than 'top'

I had been using Top; for the GC version, rsize wound up more than double the manual collection, while vsize was up about .4GB (vsize didn't budge using manual collection). I'm partway through rewriting things to thread, so i'm not really in a position to go back and make a comparison using heap.


JT
_______________________________________________

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


References: 
 >Re: Garbage collection, core data, and tight loops (From: Ben Trumbull <email@hidden>)

  • Prev by Date: [SOLVED] Re: Setting up bindings using GC and properties
  • Next by Date: Re: [Leopard] Interface Builder - Subclassing
  • Previous by thread: Re: Garbage collection, core data, and tight loops
  • Next by thread: Wrapping my head around pthreads, nsthreads, and nsnotificationcenter
  • Index(es):
    • Date
    • Thread