RetroSearch Browse

Fri Apr 20 02:24:58 EDT 2001 · http://mail.python.org/pipermail/python-list/2001-April/078312.html

On Fri, 20 Apr 2001 kragen at pobox.com wrote:

> Neil Schemenauer <nas at python.ca> writes:
> > Kragen Sitaker wrote:
> > > Reference-counting exacts very heavy performance costs, no
> > > matter what you back it up with.
> >
> > Can you back that statement up with any data?
>
> Not right now, sorry --- too busy.  But if you happen to find data on
> the other side, I'd be happy to hear about it.

So, in other words, your answer is "no".

As for data on the other side, i've never seen non-atomic reference
counting exact a huge performance penalty, in a well-designed application.
INCREF is a macro that expands to (with depythonified equivalent names) :
object->refcount++.
DECREF is a macro that expands to (with depythonified equivalent names):
if  (object->refcount--) free(object)

I'm pretty curious as to how you think this will exact a huge performance
cost.
Cache locality isn't hurt, why the heck would you decref an object you
hadn't just used? Why the heck would you incref an object you weren't
about to use?

Branch prediction isn't an issue here, you'd have the same problem in any
garbage collection schemes.

So where is the huge performance cost i'm paying?
--Dan

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-list/2001-April/078312.html below:

A couple garbage collector questions