http://www.mikeash.com/?page=pyblog/perform_better_with_garbage_collection.html#commentsmikeash.com Recent CommentsSun, 10 May 2026 04:49:05 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rsshttp://www.mikeash.com/?page=pyblog/perform_better_with_garbage_collection.html#commentsWould also love to see a followup on this with some benchmark results. <br />I also have 2 cents: recently i have came upon a memory issue inside Apple's Security framework under GC, so i second the feeling that the frameworks are not toughly tested for GC, however this particular issue is fixed in the 10.7 beta so it could be that Apple did work in this area for 10.797a354dc9c8be80ba48cfd586e5ecfbeSun, 13 Mar 2011 22:09:14 GMThttp://www.mikeash.com/?page=pyblog/perform_better_with_garbage_collection.html#commentsI finally "ported" my code to manual mode and I got virtually leak-free App (GC application was leaking 200MB/hour, now it is 100-200 kB/hour). I talk about Leopard. <br /> <br />Finding memory leaks in manual mode proved to be much easier than in GC mode. In GC mode Instruments outputs complete nonsense, most of leaks were in Cocoa internals and sometimes call stack contains no single application call (only cocoa and lower levels calls). In manual mode I had two days to get a reliable leak-free application <br /> <br />My App do issue some 20,000 NSURLConnection per hour and some 40,000 NSXMLDocument per hour. I have a strong feeling that Cocoa frameworks were not tested thoroughly in GC mode- many leaks were in NSURConnection thread, it was really disastrous experience. <br /> <br />GC app showed spinning rainbow periodically for 1-2 seconds, now it is gone, CPU usage is much lower. Thanks God I fixed the leaks problem and got responsive interface. I will try to repeat my GC experience in Snow Leopard only. <br />b61ad1450803b74c2c37c0bca7877a99Fri, 11 Sep 2009 13:24:50 GMThttp://www.mikeash.com/?page=pyblog/perform_better_with_garbage_collection.html#commentsDisabling GC did boost performance of my app in times (complex network app with sophisticated GUI and huge number of short living objects). I had big hopes on GC, all have failed - memory leaks did not disappear (t seems cocoa frameworks have very poor GC support), CPU load increased twice (profiling showed GC was a serious CPU eater and there were lots of inter-thread syncs). <br /> <br />I had to disable GC. This tech is not mature and not very good for complex real-life apps in 10.5 Leopard. I did not yet tried to enable it in Snow Leopard, hopefully implementation is better. <br /> <br />GC is a great tech in theory but poor in current implementation.ce997ea83f67fa432d7a90f81af256ffFri, 11 Sep 2009 08:43:57 GMThttp://www.mikeash.com/?page=pyblog/perform_better_with_garbage_collection.html#commentsSome good comments here. <br /> <br />Chris, you're correct that I am making some assumptions, but perhaps not as many as it looks. In particular, I'm not claiming that GC uses fewer CPU cycles than manual management. I'm only saying that, in some situations, GC will lead to a lower wall-clock time due to spinning some work onto a separate CPU core. The work that happens on the separate core may very well be significantly greater than the work that happens on the main thread under manual management, but it can still be faster overall. <br /> <br />Steve, unfortunately if I disabled GC, the thing would leak like crazy. I'm not writing any dual-mode code right now. However I did profile it and it appears that it's spending a lot of time in contention between the allocator on the main thread and the collector on the GC thread, so much of that CPU usage is probably wasted. This particular case is extremely heavy on object allocation, pretty much just sitting in a tight loop and pumping out temporary objects, so it would appear in that case that GC is not so helpful. I haven't yet tried to come up with a case that more realistically exercises the collector in a way I can properly measure both with and without GC. I did simplify the tight loop down to a test case and it performed several times slower under GC due to all the contention, so that is obviously <i>not</i> a case where GC makes you go faster.ba0cdeb9b0612f048592177588306a5fFri, 23 Nov 2007 00:40:24 GMThttp://www.mikeash.com/?page=pyblog/perform_better_with_garbage_collection.html#commentsThe other rule of thumb is to measure, not assume. Disable GC on that 200% blaster of yours, and give some real statistics. <br />5fdf8be26ddc7216c6a022f5c318d837Thu, 22 Nov 2007 18:22:07 GMThttp://www.mikeash.com/?page=pyblog/perform_better_with_garbage_collection.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">Generally speaking, GC can be faster than manual garbage collection. But it often isn't.</div></div> <br /> <br />Isn't this true of almost everything :)0067d18cd41b482871a43e7aa3d343c9Thu, 22 Nov 2007 13:13:38 GMThttp://www.mikeash.com/?page=pyblog/perform_better_with_garbage_collection.html#commentsYou're making an awful lot of assumptions about the actual performance of the GC here. Can we expect a followup post on the actual performance? <br /> <br />Generally speaking, GC can be faster than manual garbage collection. But it often isn't.537c5e770eb00353a19a31c9382b6291Thu, 22 Nov 2007 04:51:26 GMT