Incrementing and decrementing are two of the fastest things computers know how to do. Adding an increment to a call to malloc() is "in the noise" performance-wise.
True, but that's not the only place that reference counting can lose performance compared with a decent GC. You'll usually get much better cache localisation, reduced risk of pipeline hazards, and avoid much of the messy issue of synchronisation of counts across threads.
I gained about 4% speed with some Lisp-ish code a few years back when we switched from a (admittedly fairly naive) reference count to a decent ephemeral GC. Not order-of-magnitude land - but a respectable speed up. I put most of that down to the GC keeping all the live objects in cache.
Also, it's not just in the call to malloc you're adding the increment. You're doing an increment every time you add a reference to something, and a decrement every time you remove a reference to something. That happens a lot more often than malloc/frees.
That said - there isn't a "right" answer. Whether ref counting or some other GC variant is going to get you more speed depends on the code's allocation patterns, the hardware you're running on, etc. too. I just want a decent GC in perl so I can have self-referental structures without having to jump through hoops ;-)
In reply to Re^6: Parrot, threads & fears for the future. (ref counting)
by adrianh
in thread Parrot, threads & fears for the future.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |