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:26:39 +0200
> On 17 sept. 2015, at 16:00, Jean Suisse <email@hidden> wrote:
>
> Thanks. But I already have one single timer dispatch source that updates all the UI only by transferring double / int values from instance variables to bound properties. The timer fires every second and causes the whole 100+ fields to be updated. This, however, does not prevent KVO to operate for each setter being called.
> More information in my first post where you can see the implementation of the timer dispatch source and of the updateUI functions and in a previous e-mail I sent today. Data format varies based on the data being displayed (I use the formatters to display the correct physical unit for each measurement).
>
> The program is running now. Last time I check, the issue is solved just by adding this code in the UI update loop.
>
>> 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 start more and more to believe in Sandy McGuffog & Jonathan Taylor’s hypothesis :
>
>>> As I understand it (and as discussed on this list some while back I think) pools may not always be drained when you expect.
>
>> // 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.
>
>> 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.
>
>
> Cheers,
> Jean
>
>> On 17 sept. 2015, at 15:47, Gary L. Wade <email@hidden <mailto:email@hidden>> wrote:
>>
>> Okay, so what it appears you have is over 100 timers being fired whose only purpose is to transfer a single value from one variable to another so that bindings will hear that change and update your UI.
>>
>> A better approach is to remove bindings completely, make a single timer on the main queue that fires every quarter-second (I believe that was your interval from another email), which is associated with the view/window controller that manages all your text fields and instrument objects, have that timer use a single cached formatter and loops through all your 100+ objects, getting their values, formatting them, and setting each appropriate text field's string value.
>> --
>> Gary L. Wade (Sent from my iPad)
>> http://www.garywade.com/ <http://www.garywade.com/>
>>
_______________________________________________
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: Charles Srstka <email@hidden>) |
| | >Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface (From: Ken Thomases <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: 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: "Gary L. Wade" <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):