Re: Cocoa class extension best practice
Re: Cocoa class extension best practice
- Subject: Re: Cocoa class extension best practice
- From: Steve Mills <email@hidden>
- Date: Tue, 15 Oct 2013 23:13:46 -0500
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.
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
_______________________________________________
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