On Oct 18, 2010, at 8:33 PM, Gerriet M. Denkmann wrote: > First of all: Thank you very much for this very helpful article. > > I just created a new Cocoa Document based app in Xcode (Version 3.2.4). > I did not edit any of the Xcode supplied files. > Clicked Build and then Run with Performance Tool → Allocations. > The I did 10 times: > New > Close > Click "Mark Heap" in Instruments > > But there are several kiloBytes of Heap Growth in (almost) each Heapshot. > These are: > CFBasicHash (value-store) > CFBasicHash (count-store) > <non-object> > None of these have any of my code (except main()) in their respective > backtraces. > > So, what to do now? > Conclude that AppKit is full of leaks? > Investigate further? If yes, in which direction?
Investigate Further, of course! :) I just did the same thing. Try for a few more iterations. Or, more quickly, create a bunch of new document windows all at once (cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n etc),then close them all (opt-cmd-w, I think) and then mark the heap. What I saw was the earlier iterations went to zero objects. Most likely, what we are seeing -- and I should probably do a follow-up posts on some of the patterns that are non-obvious until you understand them (took me a while to figure 'em out, certainly -- is a combination of lazy initialization and self-pruning caches. In particular: • As an application runs and touches more and more of the Cocoa APIs, including touching some multiple times, subsystems will be lazily initialized. This will show up as an odd allocation here and there. • Some subsystems have caches for expensive-to-compute items such as glyph caches, image caches, and the like. These are typically keyed on some configuration information such that, for example, as long as you keep rendering text with the same configuration -- the same attributes -- you won't be recomputing glyphs. Since there is no way to know when an app will stop using a particular cache entry (at least, not within the AppKit itself), the caches are pruned automatically as they reach a certain size by pruning the least recently used item(s). • As a program runs, the backing stores of certain collections may need to increase in size. This will cause completely random, typically malloc block, allocations to pop up in the middle of a set of heapshots. In general, what you are looking for is any iteration with ZERO allocations. If you see even one iteration -- one heapshot sample -- with zero allocations, it means that the code that you are directly testing (in this case, new document, close document) **does not directly cause any permanent allocations**. b.bum _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
