Re: Tradeoffs with resources

[olson@juliet.ll.mit.edu]

	I am interested in using resources but can't tell where the break-even
	and big-win points are from the documentation.

	(1) How much consing does the resource facility do (independent of the froms
	    I supply) when an object is created?

	>None (at least on an Ivory under 8.0).  Here's how I tested it:
	>(defresource my-resource () :constructor (make-array 10))
	>11 structure words consed in WORKING-STORAGE-AREA.
	>The resource itself occupies 11 words.

Thats not right, 11 words is simply the size of the array.  The real question
is what is the resource overhead.  Each object under the control of the
resource system is associated with a little struct that has four slots; a
pointer to the object itself, a in-use flag, and two slots to hold the
creation parameters of the object.  If you have more than two parameters,
the system keeps a list of them in one of the parameter slots, adding to the
overhead.  There is also a 1d array to hold all these little structs and
about 15 slots worth of info in the array header.  The array grows as you
allocate more objects; if you have a clue as to how many objects you need,
you can specify a starting size for this array.

	(2) How much consing does the resource facility do (independent of the froms
	    I supply) when an object is reallocated?

None.

	(3) What are guidelines as to minimum size objects that are good to put
	    in resources?
	(4) How rapidly must the average object be reallocated for using resources
	    to make sense --- this question assumes that the longer the lifetime
	    of a single use, the less good the resource idea.

As other respondents have noted, pat answers to these questions are impossible.
The fundamental question is what is the maximum number of objects you
expect to have outstanding at any one time compared with the total
number of allocations/deallocations.  Also, the total size of the objects
in question should be large enough so that taking them out of the GC's
domain makes sense.

For large numbers of identical objects, a "roll-your-own" approach is feasible.
If you are dealing with flavor objects, structure objects, or arrays with
leaders, you can define a "link" slot and manage you own link chain of
free objects.  I belive that Symbolics does something similar to this with
packet buffers.  Very fast, very cheap, but it only make sense with identical
objects.

	(5) Is the resource mechanism smart enough to release, to the GC, objects that
	    are not in use when the GC is prepared to reclaim them, i.e., are objects
	    not in use copied by the GC because the "resource array" points at them?

Other respondents have pointed out how to make GC work with resources, but 
remember you don't necessarly want to do this.  If you have a free resource
object that you expect to be using in the not too distant future, why GC it?
You are going to take the time to re-create it later and GC is not free either.
It goes against the reasons for using resources in the first place.  I
often like to create resource objects in static areas, then you save the 
overhead of having them churned through the GC mill N times.

- Steve Olson
  MIT Lincoln Laboratory
  olson@juliet.ll.mit.edu