Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
- Subject: Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
- From: Charles Srstka <email@hidden>
- Date: Wed, 16 Sep 2015 12:56:21 -0500
> On Sep 16, 2015, at 11:58 AM, Quincey Morris <email@hidden> wrote:
>
> On Sep 16, 2015, at 04:00 , Jean Suisse <email@hidden <mailto:email@hidden>> wrote:
>>
>> Does anyone know what to try / measure / observe to get more clues?
>
> It seems you’re “losing” free memory fast enough for this to be visible using heap generations in Instruments’ Allocations.
If the memory’s actually being leaked, the “leaks” too might help too. Here’s how I look for something using Allocations, though:
1. Make sure the instrument is set up to record refcounts before you start (the Leaks instrument automatically sets up an Allocations instrument this way, but the Allocations instrument doesn’t by default. There’s a check box in the right-hand pane).
2. Start recording, and sort the list of objects by the “Category” field.
3. After it’s collected enough data, find the class of object that you're storing in the property that might be leaking in the list. Click the little arrow thing that appears next to it when you hover over it.
4. You’ll see a list of instances of your class. You can click the little gear icon in the right-hand pane and choose whether to show all objects, live and dead, or only live ones. Showing all objects can show you whether any of these objects have been deallocated at all; if none have, there’s your problem.
5. If you can find an instance of your class in the list that really *should* have been deallocated, but hasn’t, you can click on its little arrow thing, and get its history. You can now see all the places where it’s been alloc, retained, released, autoreleased, etc. If you click the little icon that looks like Ⓔ in the sidebar, you can see a full stack trace of the line that caused the action you’ve got selected.
You know, though, if all you’re trying to do is avoid KVO notifications getting fired on threads other than the main thread, you could just turn off automatic KVO notifications for those properties and fire them yourself on the main thread. If you just implement the (really baroquely named) +automaticallyNotifiesObserversOf<Key> to return NO, and then have your setter manually call -willChangeValueForKey: and -didChangeValueForKey: on the main dispatch queue, with a lock or sync queue to make the variable atomic (or just back it by a private atomic property), you can avoid the need for your UI update polling altogether. If your property name is “foo”, something like this (warning: written in Mail):
@interface MyClass ()
@property (atomic) MyObject *privateFoo;
@end
@implementation MyClass
+ (BOOL)automaticallyNotifiesObserversOfFoo {
return NO;
}
- (MyObject *)foo {
return self.privateFoo;
}
- (void)setFoo:(MyObject *)foo {
dispatch_async(dispatch_get_main_queue(), ^{
[self willChangeValueForKey:@“foo”];
});
self.privateFoo = foo;
dispatch_async(dispatch_get_main_queue(), ^{
[self didChangeValueForKey:@“foo”];
});
}
@end
Voilà; you can now just call the setter directly from your worker queues without any special shenanigans, and all KVO notifications for foo are now sent on the main thread; no uncommitted CATransactions or other weirdness caused by UI threads getting updated on the wrong thread.
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
- Prev by Date:
Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
- Next by Date:
Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
- Previous by thread:
Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
- Next by thread:
Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
- Index(es):