| This category allows for more efficient management of objects which go in and out of scope quickly. Because freeing
and allocating memory dynamically can be rather slow, the object recycler's job is to keep track of "freed" objects
until they are needed again. Then, the object is re-initialized and put back into action. Use of the recycler for classes
such as MiscColor and MiscString could provide fairly large boosts in performance for applications which use those
classes extensively.
To effectively use the object recycler, when you need a new object, send a +newFromRecycler message to the
appropriate class. For example, [MiscString newFromRecycler] will obtain a recycled MiscString and
re-initialize it for you. When you are finished with an object, simply send it the -recycle message instead of -free
and it will be sent to the recycler to wait until it is needed again.
If a particular class needs finer control over how it is re-initialized, simply override +firstInitObject: and
+reInitObject: to do things the right way. Normally a simple -init message is sent. If you need access to the
recycler for a particular class, it is obtained with either +recycler, +recyclerForClass:, or
+recyclerForClassName:.
There is one very important caveat when using the object recycler: do not recycle an object more than once! If you do
this, strange things will occur due to objects suddenly re-initializing themselves while in use. The best way to avoid
this is to make sure you set all pointers to an object to nil when you recycle it. If you tend to be scatterbrained, and feel
that the recycler should keep track of this for you, recompile the source with MISC_SLOW_BUT_SAFE defined. (It is
commented out in the source file; just uncomment it and recompile.) If you never have very many objects in the
recycler at any given time, you won't take much of a performance hit. By defining this, however, you change the
algorithm for recycling objects from O(1) to O(n) where n is the number of objects in the recycler.
|