At 09:49 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" <[EMAIL PROTECTED]>
>wrote:
>
> >Actually I was thinking something like PMCs ($@%) being copy-GCed and
> >referred objects (new SomeClass) being refcounted. In this case above, every
> >operation would use refcount's, since they're storing objects in PMCs. What
> >wouldn't use refcount is
> >
> > foreach $i (@a) {
> > $i++;
> > }
> >
> >Normally $i would be an alias to an element of @a, that means it would
> >reference the same PMC that one element of @a is referring to. If in this
> >case copy-GC is used, probably the GC wouldn't even be called inside of the
> >loop, and the whole operation would be done without overhead, even of
> >refcounting, even of copy-GC.
>
>I would help if we kept in mind when reference counts are actually being
>accessed. Your loop above doesn't use reference counts even in the
>current implementation. Reference counts come into play when you
>introduce a lexical variable, create a reference to another variable or
>when you do end-of scope cleanup (provided the scope contained lexicals).
Sort of wrong. Refcounts are altered every time a [SAHG]V * is created,
destroyed, or stuck in an aggregate. That loop doesn't alter refcounts, but
pretty much every non-aliasing operation you do with them will affect them.
>Also note that incrementing/decrementing the refcount is really cheap:
>The refcount is in the SV itself (no indirection) and you only execute a
>single inc/dec machine instruction for it.
Individual reference count increments are cheap. Lots and lots of
increments are not cheap. Decrements aren't nearly as cheap as increments,
since they're all decrement-and-test operations, with a cleanup if the
decrement brings you to zero.
>Going to partial refcounts does increase the runtime overhead for *all*
>variable:
>
> inc(sv->refcount)
>
>becomes
>
> if (sv->flags && REFCOUNTED)
> inc(sv->refcount)
>
>This is definitely slower for refcounted variables and probably at least
>not faster for non-refcounted ones: I think the bitmask test and
>conditional jump instruction will most likely take as much time as inc()
>takes longer than just a memory fetch.
The only place you need to deal with refcounts, or the fact that a variable
has been referenced at all, is when a reference is actually taken,
destroyed, or copied. Generally speaking, this happens rarely in a program.
Yes, it may mean scope exit for scopes containing references will be more
expensive, or that dealing with references themselves is slightly more
expensive. I don't think that this happens often enough that we'll see a
performance loss from it, and if we do we can try plan B.
Even if we *do* end up with reference counting as our primary method of
determining object life (which I don't think we will), deferring and
coalescing all the destruction will save us some time. I don't think it'll
come to that, though.
I'll get something more formal put together in the next few days, so we can
have something solid to work over, rather than the vague notions we're
chewing on now.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
