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: Jonathan Taylor <email@hidden>
- Date: Wed, 16 Sep 2015 19:29:23 +0100
Hi Jean,
A wild guess that might or might not have any relevance to your problem: I see that you are wrapping your blocks with an autorelease pool, and that reminded me of a problem I dealt with a while back.
As I understand it (and as discussed on this list some while back I think) pools may not always be drained when you expect. I'm not sure if that applies to explicitly generated ones, but it certainly seems to apply to little snippets of callback code (e.g. UI accessors) that may be called from within the main event loop. I have a dim recollection there may be some funny stuff with GCD-related code as well.
Anyway, I have the following little bit of code in my application. I don't remember all the details now, so the comment itself (and perhaps a trawl through the list archives for that text) will have to serve as an explanation:
// Create a periodic timer that "tickles" the main event loop to drain autorelease pools.
// Response from cocoa-dev discussion was that:
// This is a long-standing problem with AppKit. According to the documentation,
// "The Application Kit creates an autorelease pool on the main thread at the
// beginning of every cycle of the event loop, and drains it at the end, thereby
// releasing any autoreleased objects generated while processing an event."
// However, this is somewhat misleading. The "end" of the event loop cycle is
// immediately before the beginning. Thus, for example, if your app is in the background
// and not receiving events, then the autorelease pool will not be drained. That's why
// your memory drops significantly when you click the mouse or switch applications.
[JDispatchTimer allocRepeatingTimerOnQueue:dispatch_get_main_queue() atInterval:5.0 withHandler:^{
NSEvent *event = [NSEvent otherEventWithType:NSApplicationDefined location:NSZeroPoint modifierFlags:0 timestamp:[NSDate timeIntervalSinceReferenceDate] windowNumber:0 context:nil subtype:0 data1:0 data2:0];
[NSApp postEvent:event atStart:YES];
}];
I wonder if that would be any help with your case - either for the exact reasons I encountered, or for some reason along similar lines. It just might be a wild stab in the dark at a quick (but obscure) fix, but if it doesn't help then I guess you'll have to start exploring things with Instruments as others have suggested.
Cheers
Jonny
_______________________________________________
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):