> On 1 jan 2015, at 18:22, Roland King <r...@rols.org> wrote: > > +1 for all of this. I wouldn't call leaks an utter waste of time, but it > really does only find pure retain cycles (which it then annotates very > nicely) and not memory which is really is pinned by a real reference which is > more often the case. Also, if you're using KVO anywhere, this tends to > entirely defeat leaks even though KVO isn't a strong reference and shouldn't > be treated like one, it is. That makes leaks less useful than it could be for > me because I'm always KVO'ing something.
I don't think leaks would find cycles. I could be wrong, but I don't think it's sophisticated enough to perform that additional level of analysis. I think it only finds stuff that's truly referenced from nowhere else on the heap. > There's an old blog by bbum which covered using generational analysis for > finding leaks which aren't leaks. Xcode has changed quite a lot since then > but some of the screens look quite similar even now. I routinely put my code > through this torture test, it's so easy to run and the results are often very > illuminating. > > http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/<http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/> That functionality has since been integrated into Instruments, so it's easier to use. Joar _______________________________________________ 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
