> On 17 sept. 2015, at 16:00, Jean Suisse <jean.li...@gmail.com> 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 <garyw...@desisoftsystems.com >> <mailto:garyw...@desisoftsystems.com>> 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 (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
