Re: Cocoa class extension best practice
Re: Cocoa class extension best practice
- Subject: Re: Cocoa class extension best practice
- From: Charles Srstka <email@hidden>
- Date: Wed, 16 Oct 2013 02:31:16 -0500
On Oct 15, 2013, at 11:13 PM, Steve Mills <email@hidden> wrote:
> On Oct 15, 2013, at 17:22:26, Graham Cox <email@hidden>
> wrote:
>
>> OK, so if that's the case, I'm interested in knowing whether each call to -itemArray returns the same object or a different one each time. If it's different, then it's either a copy of some internal array or something built on the fly.
>
> It's a different object - like I mentioned, it's an __NSArrayI* where the member variable of NSMenu is an __NSArrayM*, and the addresses are indeed different. What's pissing me off right now is that I can't reproduce it again, and I haven't changed any code (the couple tests I made have been reverted). Ack! I'm going to try adding a signal flag to the method that calls itemArray that was previously showing the hundreds of arrays being copied so I can narrow right down to that code in the Allocations trace.
>
> *time passes*
>
> Ah, here it is again. So here's the section of allocations between the first and last call to itemArray. Nearly all of these are caused by a call to itemArray:
>
> Graph Category Live Bytes # Living # Transitory Overall Bytes # Overall # Allocations (Net / Overall)
> 1 * All Allocations * 524.55 KB 8448 165275 80.14 MB 173723 <XRRatioObject: 0x7fb11094e640> %0.02, %0.34
>
> That shows over 8000 of these pointers are still living, and I know there aren't 8000 menus. Here's a typical stack for most of the calls to itemArray:
>
> 0 libsystem_c.dylib calloc
> 1 libobjc.A.dylib _class_createInstanceFromZone
> 2 libobjc.A.dylib _class_createInstance
> 3 CoreFoundation __CFAllocateObject2
> 4 CoreFoundation +[__NSArrayI __new:::]
> 5 CoreFoundation -[__NSPlaceholderArray initWithObjects:count:]
> 6 CoreFoundation -[NSArray initWithArray:range:copyItems:]
> 7 CoreFoundation -[NSArray initWithArray:copyItems:]
> 8 CoreFoundation -[__NSArrayM copyWithZone:]
> 9 libobjc.A.dylib -[NSObject copy]
> 10 AppKit -[NSMenu itemArray]
> 11 Finale 2014 -[NSMenu(FCExtensions) itemWithTag:searchSubmenus:depthFirst:]
> 12 Finale 2014 -[NSMenu(FCExtensions) itemWithTag:searchSubmenus:depthFirst:]
> 13 Finale 2014 -[NSMenu(FCExtensions) itemWithTag:searchSubmenus:depthFirst:]
> 14 Finale 2014 -[NSMenu(FCExtensions) itemWithTag:searchSubmenus:]
> 15 Finale 2014 MenuEnable(EMENU, long, bool)
> 16 Finale 2014 FinPlugIn::AdjustMenuItems(EMENU, bool) const
> 17 Finale 2014 FinPlugInList::AdjustMenuItems(EMENU, bool) const
> 18 Finale 2014 FXMI_AdjustMenuItems(EMENU, bool)
> 19 Finale 2014 -[FinaleAppDelegate validateMenuItem:]
> 20 AppKit -[NSMenu _enableItem:]
> 21 AppKit -[NSMenu _enableItems]
> 22 AppKit -[NSMenu update]
>
> This is running our release target. Zombies is off. Am I just not reading this data correctly? These do NOT appear as leaks in the Leaks instrument, only as allocations in the Allocations instrument. If I run this particular code over and over, I can watch the app's memory footprint grow steadily, yet Leaks shows nothing out of the ordinary.
>
>> So that might lead you to look at how and where these methods are being called, e.g. sure they're on the main thread, within a runloop event handler of some sort?
>
> The main run loop and some modal loops that are started and ended for a modal dialog I was using to exercise some code.
Just out of curiosity, what kind of run loop are you running in? I ask because the older Finale 2012 appears to use a Carbon run loop while using some Cocoa elements here and there. Is this still the case, or have you switched to a Cocoa NSApplicationMain() - based architecture?
I ask because if you're not using NSApplication's run loop, you won't get an automatic release pool, which would explain what you were seeing. If this is the case, then wrapping whatever event loop you're using in an @autoreleasepool would probably solve the problem.
Charles
_______________________________________________
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