> On 4 Sep 2015, at 16:55, Scott Ribe <scott_r...@elevated-dev.com> wrote: > I would not be surprised if that callback to an observer is something > triggered by your updates--some part of the window event/update/redraw > handling deep in the framework. I don't have any advice to offer as to how to > get from that suspicion to a solution, sorry. But varying the frequency of > your updates, and checking to see if that drives the rate of leakage through > the observer callback, will at least establish if it's truly independent or > correlated. > > If it is correlated, then the prior suggestion of stripping down your update > code bit by bit is a good one. I'd make one change though, first I'd remove > *all* the code in the NSTimer callback. Find out if simply having a timer > fire is enough, or if you have to actually do some updating--then if it > doesn't leak with no code, start adding back gradually. And of course if it > does leak with no code, you're ready to file a bug report and/or open a DTS > incident.
With no code, or even with all the code except for updating the UILabels, there is no leak. With any UILabel updates, there is a leak whose rate is independent of the number of UILabels being updated. The rate goes up with the timer frequency, but not proportionally. In the message I found on the gamedev.net forum from March 2014, and I linked in another reply here, the leak was triggered by updating a slider, and the writer there says that further experimenting gave this leak when updating any sort of GUI element. I've joined that forum and sent him a message, but he may no longer be active there. -- Richard Kennaway _______________________________________________ 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
