You gained a 4% increase in performance after removing what you don't consider a very good implementation of reference counting? Yep, you've pretty much made my point. Corion's wording was "Of course, Perl sacrifices a lot of performance to the reference counting", which your numbers certainly refute. I suspect Corion's wording closely matches what was claimed in support of not doing reference counting in Parrot.

Since you describe the ref counting as "fairly naive" and the GC as "decent", the 4% could easily have more to do with quality of implementation than anything else. You've mostly placed an upper bound of 4% on what one might expect in performance improvement going from RC to GC in such a situation. It sounds likely that a "decent" RC could easily give better performance than your decent GC in that situation.

But even 4% is peanuts. The original use of performance as one reason to justify not doing ref counting obviously didn't imply "RC has too high of a performance cost (4%) and therefore cannot be considered", because that'd just be laughable.

I put most of that down to the GC keeping all the live objects in cache.

That sounds like wishful thinking, sorry. One of the worst performance impacts due to cache problem that I recall was caused by declaring an large, multi-dimensional array in the wrong order so that interating through the array jumped across the array and kept way too many of the "live" elements of that array in the memory-resident working set of the process. I want items to be "in the cache" because I used them recently, not because the GC has yet again swapped in every single item that wasn't supposed to have already been free()d, forcing my working set to contain every single thing I've ever allocated, even if I have no use for 95% of them in the near future.

The potential performance penalty for forcing the working set size up is several orders of magnitude. So getting a 4% performance boost in a best-case in exchange for huge performance penalties in other cases isn't a good trade-off in my book. I'm much more likely to optimize space utilization over CPU utilization because when you run up against the available cache size your performance penalty gets huge fast while decreasing CPU utilization only offers linear gains.

I wasn't claiming that RC is wonderful and GC is horrid. I was just refuting the oft-repeated point that RC is "very slow". There are certainly advantages to GC. There are certainly advantages to RC. I'd personally rather have both with the option of choosing to not use one or the other (rebuilding the tool would probably be required to make such a choice). If I can only have one, I find it easier to deal with the limitations of RC than to lose its advantages.

But, clearly, RC is not "very slow". And, now that you've reminded me, I don't find it hard to envision a scenario where GC would be very, very slow. So thanks. (:

Also, it's not just in the call to malloc you're adding the increment.

I never said otherwise. You can even see that I understand this because I later say that you'd have to be making and destroying a lot of references without doing much other real work for inc/dec to make much impact. As for your claim of "a lot more" (with an emphasized font for "lot"), I'm doubtful that such emphasis is justified. I wouldn't be surprised if the cost of malloc() still out-weighs the cost of all those inc/decs.