Adopting Garbage Collection

Garbage collection provides trade-offs that you need to consider when choosing whether to adopt the technology.

Potentially, any application that uses a runloop may use garbage collection, however there are issues you should consider when deciding whether it is appropriate for your application. Garbage collection provides several advantages when compared with manual reference counting—although some of these are diminished or negated with Automatic Reference Counting (ARC—see Transitioning to ARC Release Notes); there are also, though, some disadvantages. The benefits tend to be greater if the application is threaded and has a reasonably large working set; they tend to be less if the latency of memory recovery is important. Moreover, reference-counted and garbage collected applications use a number of different idioms and patterns.

Advantages and Disadvantages

Garbage collection offers some significant advantages over a manually reference-counted environment (as described in Advanced Memory Management Programming Guide):

Garbage collection does though have some disadvantages:

Performance

The performance characteristics of an application that uses garbage collection are different from those of an application that uses reference-counting. In some areas, a garbage-collected application may have better performance, for example:

In other areas, however, performance may be worse:

When analyzing the performance of a garbage-collected application, you typically need to take a longer-term approach than with a reference-counted application. When assessing its memory footprint, it may be appropriate to measure after the application has been running for several minutes since the memory footprint may be greater shortly after launch. The profiling tools you can use include heap, gdb flags, and the Instruments application.