Re: Continuously running daemon process CFConstantStringRefs build up over time
Re: Continuously running daemon process CFConstantStringRefs build up over time
- Subject: Re: Continuously running daemon process CFConstantStringRefs build up over time
- From: Kevin Ross <email@hidden>
- Date: Fri, 1 Oct 2010 14:30:53 -0700
Thanks a million Scott,
I've started reading the sqlite documentation and it looks like I can adjust the PRAGMA cache_size to let me tweak the size of the cache. I am only writing to the database with this daemon and I'll try to dig up any other options that might help optimize it for this scenario. Those were the largest allocations in my testing and setting the cache to 10 seems to eliminate the outstanding malloc'ed objects.
I still have some outstanding allocations from -[NSAutoeleasePool init] and +[NSRunLoop(NSRunLoop) currentRunLoop] that Foundation must be caching, but the memory overhead has drastically reduced under stress-testing.
While I'm on the subject, are there any caveats to calling [[NSRunLoop currentRunLoop] run]; in the -(void)main of my NSOperation subclass? In my testing it works wonderfully but I haven't read anything in the docs that say to avoid it.
Thanks again for your help,
Kevin Ross
On Oct 1, 2010, at 1:20 PM, Scott Ribe wrote:
> On Oct 1, 2010, at 2:15 PM, Kevin Ross wrote:
>
>> libsqlite3.dylib mallocs 35 objects that are still considered "live"
>
> Sqlite manages its own cache.
>
> --
> Scott Ribe
> email@hidden
> http://www.elevated-dev.com/
> (303) 722-0567 voice
>
>
>
>
>
_______________________________________________
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