On Sep 16, 2015, at 14:28 , Jean Suisse <jean.li...@gmail.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
