> What makes you think that:
>
> (a) this is a lot of activity?
It is not a lot of activity. I am not trying to do performance optimization.
Right now, the app is taking 3 % CPU on the latest 13” MBP Retina.
I am trying to find why my app can’t run for two days without exhausting the 16
GB RAM it has.
> (b) your monolithic replacement runs faster than this?
I don’t know, but as long as it runs reasonably I am not sure I care. The MAC
is dedicated to the project. There is no user to complain. All I can tell is
that there is no visible jump in CPU consumption.
> 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.
Well, at this point it is better for me to say more.
It is a scientific data acquisition app. Basically, I mad many electronic
boards performing various tasks (actuation & measurements mainly). These
electronic boards have been incorporated in nice boxes to build what I will
call hereafter “instruments”.
These instruments either communicate wirelessly or not, depending on their
physical location, and use different protocol (buses, interfaces) according to
their nature. All these instruments together allow me to cover a large area and
monitor around 150 parameters every second.
The application does that. Of these 150 variables, a little above 100 are
displayed on a UI that is refreshed every second.
This in itself is a challenge and I had to add some piece of electronics, work
on the (custom) protocol and on the firmware of the boards to get it to work
reliably. Especially for the wireless part. One solution was to have distinct
data buses (distinct communication interfaces).
Now, this job is done and the design of the app reflects some of these
constraints.
First, I have a communication interface server which ensures that there is only
one instance representing each data bus connection. Same for the electronic
board server. It ensures that that there is only one object for each physical
board and communication interface (so dealing with concurrency is dead simple).
Then I have actuator objects, sensor objects, instruments objects all
requesting their electronic board on their bus to these object servers. I
manipulate the instruments objects. Communication follows. Communication is
slow. It is expected.
Then, I have one dispatch source that takes care of synchronization &
timestamps. Four that trigger data collection from the devices through the 4
buses (1 wireless, 2 RS-485, one GPIB), one that collects measured values
during the last cycle, takes care of the processing & on the disk storage. And
now, one extra that sync the UI.
Everything works fine with no leaks, except for that last part. This is where
the issue lies. The timer dispatch source that syncs the UI is dead simple. It
only sends updateUI to each object representing an instruments.
These objects are declared as:
@interface MyInstrument : JSScientificInstrument
{
double aMeasuredValue;
}
@property (readwrite) double theMeasured Value; // IB binding
NSTextField with NSFormatter
@end
And implemented as :
- (void)updateUI
{
assert([NSThread isMainThread]);
self.theMeasuredValue = self->aMeasuredValue;
}
Somewhere in those lines is the issue. If I only comment "self.theMeasuredValue
= ... “, the issue disappears, despite the fact that I am only transferring a
double through a setter bound to the UI.
I believe it is somewhere in the way GCD, appkit, Core Animation, cocoa
bindings are implemented. So at this stage I am looking to pinpoint the issue
and find a workaround.
> On 16 sept. 2015, at 23:54, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> 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/erwin.namal%40gmail.com
>
> This email sent to erwin.na...@gmail.com
_______________________________________________
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
