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: Quincey Morris <email@hidden>
- Date: Wed, 16 Sep 2015 21:54:14 +0000
On Sep 16, 2015, at 14:28 , Jean Suisse <email@hidden> wrote:
>
> I thought of that at first, to solve the uncommitted CA transactions issues. But the syntax is ugly.
Sure, but in modern Cocoa programming it’s a standard pattern, so it’s not unreasonable to grin and bear it.
(It’s about a million times less ugly in Swift. Just sayin'.)
> And I didn’t want to post blocks from all over the place to the main thread (I have 100+ NSTextfields with number formatters updated every second… meaning as many blocks…).
What makes you think that:
(a) this is a lot of activity?
(b) your monolithic replacement runs faster than this?
Indeed, if the “obvious” approach leads to your app using 100% of a single CPU for days on end, is that a consideration? If so, then what is the allowable threshold? 50% of a CPU? 10%?
That’s what I mean about premature optimization. You don’t really know yet what problem you need to solve.
> The issue, to me, is to get my app to run for a few days without crashing. The only way I have to make it work, currently, is by not updating the UI.
Sorry, I was pontificating a bit in my previous post. I guess I still am.
In design terms, you have two instances of the MVC pattern, not one. You have inputs (V-1) updating a model (M), and you have UI elements (V-2) tracking the same model (M). So you have two design problems: input to model, and model to UI. It’s much harder to try to solve inputs-to-UI in a single coordinated step — nor do I think you need to.
I know nothing of the details of your app, of course, but if, for example, only 20% of the inputs change every second, then suppressing input-to-model updates entirely, at the source, seems like a good approach to performance problems, without involving the UI. Separately, if the overall rate of UI updates is very high (in particular if it’s over 100% per second), then using a timer to limit the model-to-UI update rate sounds like a simple approach, without involving the inputs.
_______________________________________________
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>) |
- 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):