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: Jean Suisse <email@hidden>
- Date: Thu, 17 Sep 2015 16:27:21 +0200
> On 17 sept. 2015, at 14:58, Jean Suisse <email@hidden> wrote:
>
> Thank you for this advice!
>
> My app has tabbed views that are implemented through the toolbar. When I switch view, some memory indeed gets released. Sometimes a little, sometimes way much more, but never everything.
>
> However, I am investigating Jonathan Taylor’s suggestion (see below). Looks like gold. I have added
>
>> 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];
>
> in my UI update loop. No more leak in simulation mode (with fake Instruments). These afternoon (it is 3 pm for me) I plan to test it on the prototype. Result in two hours time.
> There seems to be more than what Jonny describes, because switching app or views isn’t enough for me.
>
> Meanwhile, I am interested in learning how to drop Core Animation. I don’t feel like I’m using it (NSTextFiels updates on the UI).
>
> Cheers,
> Jean
> -----------
> Jean Suisse
> Institut de Chimie Moléculaire de l’Université de Bourgogne
> (ICMUB) — UMR 6302
>
>
>
>> On 16 sept. 2015, at 20:29, Jonathan Taylor wrote:
>>
>> 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
>
>
>
>> On 17 sept. 2015, at 14:15, Sandy McGuffog <email@hidden <mailto:email@hidden>> wrote:
>>
>> Based on that, where you’re losing memory is to bitmapped backed CALayers that aren’t being released. Depending on the size of the bitmap, they can be big - MBs each. They are being allocated in the Kernel, so aren’t showing in instruments. Why they aren’t being released, I couldn’t say. Maybe a retain loop, maybe an animation that never finishes, etc, etc. But I’d starting looking (a) by removing any Core animation you can, and (b) I’d look at any NSWindows/NSViews/NSControllers that aren’t being released when you close all visible windows.
>>
>> Sandy
_______________________________________________
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
| References: | |
| | >Lost memory, GCD, dispatch sources, Cocoa bindings & User interface (From: Jean Suisse <email@hidden>) |
| | >Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface (From: Quincey Morris <email@hidden>) |
| | >Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface (From: Jean Suisse <email@hidden>) |
| | >Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface (From: Sandy McGuffog <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):