From: Michael Selig <michael.selig@...>
Date: 2008-10-11T09:24:29+09:00
Subject: [ruby-core:19291] Re: performance of C function calls in 1.8 vs 1.9

On Sat, 11 Oct 2008 00:04:04 +1100, Paul Brannan <pbrannan@atdesk.com>  
wrote:

> What options did you pass to configure when you built ruby?

Only default ones - nothing special at all. I am using Ubuntu Linux 8.04  
with gcc version 4.2.3.

I am at a loss to explain the differences between your numbers and mine,  
sorry. My 1.8.6 build is fairly old, and I can't remember how it was built  
and I no longer have the src, so I guess it could be the culprit, but  
other benchmark comparisons with 1.9 seem about right. If I had the time,  
I'd re-download the 1.8 source and re-build it to ensure that I used the  
same flags and same compiler.

> Also interesting.  Using for instead of #each is usually a significant
> improvement, because it doesn't create a new scope (and thus the loop
> variable is a local variable instead of a dynamic variable).  Here there
> is no loop variable, so #times avoids the assignment altogether.
>
> However, I wonder why for is so much slower on 1.9:

Yes, there appears to be an issue with the performance of "for" loops,  
which was also pointed out a couple of weeks ago on ruby-core.

Actually my understanding is that in 1.9 the implementation of "for" is  
now much the same as "each" except for the way variables in the block are  
accessed. I think the way it now works is that a new scope *is* created  
(even though it won't hold much), and the dynamic loop variable is copied  
to the "for loop" local variable on each iteration. However I believe that  
the "new scope" overhead is much smaller on 1.9, so I would expect the  
"for" and "each" performance to be very similar to eachother in 1.9, maybe  
with the "for" marginally slower due to the extra copy.

I cannot understand why "for" seems to be this much worse though. Of  
course this is more noticible when the loop is very tight, as in your  
benchmark.

If I get some spare time, I'll try to figure out why this is the case (I  
enjoy doing that sort of thing!).

Cheers
Mike