On Sep 5, 2015, at 13:41 , Richard Kennaway <rich...@kennaway.org.uk> wrote: > > With a timer interval of 0.01, the MacBook Pro shows about 2 new 32-byte > allocations per second, and the iMac shows about 100 per second.
I repeated the test, with that smaller interval, and yes I can see a very slow increase in #Persistent, but not in a similar pattern to what you saw. I ran for about 20 minutes, and the *last* increase I saw occurred about the 11-minute mark. The total increase, after the first couple of thousand ticks, was about half a dozen objects. It’s very doubtful to call what I saw a leak. It could easily have been growth of a cache. At that rate, the cache might only need to be emptied every few *days* — less, in “real” life, since the test is an artificial pattern of app behavior. You can, and should, submit a bug report, since you have a clear behavior and a test project to reproduce it. I’m not sure there is much else that you can usefully do. If your app is supposed to be (in effect) counting seconds over the long term and you don’t want it to crash, you can perhaps form an estimate of how long it might be expected to run, by using your 100-fold speed increase and letting it run until that crashes, if ever. Multiply the time it ran by 100. (But it’s meaningless to do this in the simulator. You’d need to use an actual iOS device.) If the memory increase is intolerable, you could try using something other than a NSTimer (e.g. a GCD timer, or some asynchronous API that has a timeout). Other than that, you may just have to let go of it. _______________________________________________ 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
