> CFStringRef hexStringRef = CFStringCreateWithFormat( NULL, NULL,
> CFSTR("%x"), versionValue ); <- Instruments is hi-lighting this line as
> an allocation.
It sounds like you found the cause of your persisting string objects
so the details of CFSTR is irrelevant, but to clarify an
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 sc
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
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
___
Coc
Thanks for your insight Dave,
In my current implementation I do have an autorelease pool being created and
released at the end of main, as well as inside each posted notification that
NSFileHandle posts on each background thread. Upon further inspection the
largest culprits are not CFConstantS
Since you're writing a daemon, you'll need to handle autorelease-pool
creation and draining manually (something that's normally handled by
NSApplication in standard AppKit apps.) Perhaps objects are
autoreleased and placed in the root autorelease pool (that you might
be creating in main() or the li
Greetings Cocoa Developers,
I have run into a snag while writing my background daemon and I was hoping that
there might be some people on this list that could point me in the right
direction or suggest a workaround. I am writing a background daemon to handle
to field incoming software update r
