[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Tradeoffs with resources

   Date: Thu, 20 Sep 90 23:35:30 EDT
   From: barmar@think.com


   The general idea is that you use resources when it's cheaper to search for
   an acceptable object than to repeatedly allocate them.

I think this is a key point, so I'll elaborate a little.  Note that
when you create some objects, such as arrays (and structures are
created out of arrays) there is quite a bit of argument checking and
initialization (allocating that size memory, initializing the header
portion with array size, array type, fill pointer, etc., and filling
the elements with NIL or whatever) before you get your hands on it and
can fill it with your own data.  If you can leave the deallocated
objects partially initialized (e.g., structure type and some slots of
a structure) you may be able to win a little more.  The idea is that
if all this initialization is taking significant time in the inner
loop of your computation, and you can avoid it by using a much quicker
match function in resources, then using resources may very well help.

But if all this initialization ISN'T taking a significant time in the
inner loop (or a match function would take almost as much time), then
using resources may not help.  No one wants to waste their time
worrying about low level allocation efficiency where it doesn't matter
(as a stereotypical C programmer might), so METER the running
application first, to make sure initialization is a significant time

   <in a preceding paragraph, barmar wrote>
   It often makes sense to use areas along with resources.  Resource object
   constructors probably shouldn't allocate in ephemeral areas, since their
   lifetimes aren't consistent with the assumptions that EGC is optimized for.

E.g., it may help improve the locality of objects in a resource, so
searching through them is less likely to produce page faults (but
hopefully your search function won't have to be very picky).

Another usage pattern: If problems are being caused because large
numbers of your objects are outliving the EGC generations and must be
dynamically GC'd, it may make sense to put them in a different area
and perhaps adjust the EGC parameters for that area.  I think this
kind of strategy may be as effective as using resources in this
situation.  (But I admit I'm speculating; I don't have an actual
experience with this one.)