On 2 Jul 2011, at 18:35, Thomas Davie wrote: > > It's interesting that you cite that GC is both faster and lower memory > overhead – Apple's stated reasons for implementing this were that GC was both > too slow and too memory intensive to use sensibly on iDevices and that ARC > was both faster and less memory intensive.
Reality is probably a little more subtle than this. In general, and specifically for long-running and memory intensive processes (such as used in servers), quality garbage collection (and especially compacting garbage collection) are probably more efficient overall. Apple already supported (and continues to support) garbage collection for Objective-C in their desktop systems. The primary motivation (as I understand it) for developing ARC is to bring (mostly) automatic memory management to the iOS platforms. There are 2 reasons that I've heard why Apple considers ARC a superior solution for the iOS platform: 1. iOS devices are much more resource constrained than a desktop system. Therefore the delay that garbage collection causes before memory is available for re-allocation can have a much greater effects on application. 2. Running a background garbage collector can introduce unpredictable pauses in your application, which would destroy the illusion of immediacy that is one of the prime characteristics of good iOS apps. So for iOS immediate memory release and predictable performance trumps overall average performance. To see if this technique would be at all useful for Haskell, you'll have to evaluate these points in the context of a Haskell application and decide which trade-off brings you the most benefit. Maarten _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
