Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

>> Additionally, I was unable to find any leaks with Instruments (but I barely >> know how to use it) > > Probably the next step would be to learn more about Instruments. I was a little to harsh when I said that. I know everything I got from the WWDC videos. But I need more practice. And more

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On 16 sept. 2015, at 18:58, Quincey Morris > wrote: > > On Sep 16, 2015, at 04:00 , Jean Suisse wrote: >> >> Does anyone know what to try / measure / observe to get more clues? > > It seems you’re “losing” free memory fast enough

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

> 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

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

Thanks for your reply. > > I don't see why you're using a strong reference from the weak reference > inside your timer. You may be confusing ARC with that and your etc code. > Change your code to just use weakself rather than strongself when calling > updateUI. If there's a strong reference

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

I have been looking at this issue for several weeks now. I could easily do what you suggest, or I could design the app with the “resume on re-launch” functionality and have it quit periodically based on memory criteria. Both are last resort to me. I would rather like to figure out what in GCD

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

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

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

Also, in case you're pulling multiple values per instrument object in your new timer (e.g., temperature, time, frequency, etc.), and these may be updating on background threads, a simple way to get these is to pull all the values needed into local variables in a synchronize block based on the

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

Thanks for your reply. If I understand you correctly, I am already doing all that by having one updateUI function per instrument, which does: self.myProperty = self->myStorageVariable on every variables. All updateUI selectors are sent to all instruments, at the same time, from the main

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

> On 17 sept. 2015, at 16:00, Jean Suisse 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

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On 17 sept. 2015, at 14:58, Jean Suisse 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

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

Just as I thought. You're overloading the system by tightly coupling your model and your view. Let your instruments (models) do their work, and let your controller consult them when ready and update the view; don't use your controller to tell the models to update the views. Using an office

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

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

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

OK, I understand. That was an exemple. The 100+ variables are spread on four Instruments. So I call 4 updateUI functions sequentially. There is no difference with having everything in a single function. Since I chose to use bindings directly on the instruments properties for this project (not

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

Yes, I saw that code, but it only set a single variable and appeared to only be associated with a single instrument. If you have 100+ instruments, that would be 100+ separate updates. You know your code better than I and may be simplifying things for us, but I've seen cases sounding very much

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

From what you write, that’s already what I do. > Just as I thought. You're overloading the system by tightly coupling your > model and your view. Let your instruments (models) do their work, and let > your controller consult them when ready and update the view; don't use your > controller to

Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

Dear All, I have an app that uses Cocoa and dispatch sources leaking a lot (ca. 5GB / 17h). The origin seems to come from a combination of dispatch sources, Bindings & Core Animation. Below is a brief description of the app, what issues I encounter and the related code. DESCRIPTION OF THE

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

On Sep 16, 2015, at 04:00 , Jean Suisse wrote: > > Does anyone know what to try / measure / observe to get more clues? It seems you’re “losing” free memory fast enough for this to be visible using heap generations in Instruments’ Allocations. The difficulty with marking

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On Sep 16, 2015, at 4:00 AM, Jean Suisse wrote: > > Additionally, I was unable to find any leaks with Instruments (but I barely > know how to use it) Probably the next step would be to learn more about Instruments. > and the amount of memory reported by Instruments is

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

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

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

Hi Jonny, I also have a feeling the issue lies somewhere between the dispatch mechanism and Core Animation. I have seen some funny things too. For instance, I can’t run a serial queue for months. Some objects escape the autorelease pool created in the block (and seemingly encompassing

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

On Sep 16, 2015, at 12:56 PM, Charles Srstka wrote: > - (void)setFoo:(MyObject *)foo { > dispatch_async(dispatch_get_main_queue(), ^{ > [self willChangeValueForKey:@“foo”]; > }); > > self.privateFoo = foo; > >

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On Sep 16, 2015, at 1:45 PM, Ken Thomases wrote: > > This is not legitimate. The -willChangeValueForKey: must occur before the > property, as seen via its getter, has changed. This is necessary for > observers who ask for the old value, which can include KVO itself

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On Sep 16, 2015, at 2:49 PM, Charles Srstka wrote: > > - (instancetype)init { >self = [super init]; > >if (self == nil) { >return nil; >} > >return self; > } Oops, please disregard the empty init method in here; it’s an artifact from some I

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

> But I agree that this all (meaning the contortions to get updates onto the > main thread) seems like too much flash and not enough bang. The easiest way > would be to dispatch the original update code in blocks onto the main thread > asynchronously, thus serializing them and generating KVO

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

I can't help but think that there should be a way to use xpc services as a nice solution to this problem. Unfortunately xpc services are mostly designed around the idea that if the service dies the app can restart it when it needs. Whereas you need the service running your experiment and

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

On Sep 16, 2015, at 14:28 , Jean Suisse 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

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

On Sep 16, 2015, at 11:45 , Ken Thomases wrote: > > This is not legitimate. The -willChangeValueForKey: must occur before the > property, as seen via its getter, has changed. This is necessary for > observers who ask for the old value, which can include KVO itself for

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On Sep 16, 2015, at 11:58 AM, Quincey Morris > wrote: > > On Sep 16, 2015, at 04:00 , Jean Suisse > wrote: >> >> Does anyone know what to try / measure / observe to get more clues? > > It seems you’re

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

I don't see why you're using a strong reference from the weak reference inside your timer. You may be confusing ARC with that and your etc code. Change your code to just use weakself rather than strongself when calling updateUI. If there's a strong reference needed, try using self only. Also,