Re: Pyrex method 10x slower than Python, any hints why?

On 2/06/2006 12:21 PM, Andrew Bennetts wrote:
> On Wed, May 31, 2006 at 03:40:43PM -0700, David Chiang wrote:
> [...]
>>    against a Pyrex equivalent
>>    
>>        def estimate(self, rule.Rule r):
>>            cdef float sum, cost
>>            cdef int i
>>            sum = 0.0
>>            for i from 0 <= i <= r.e.arity():
>>               cost = lookup_words(self.ngram, None, [r.e.getchunk(i)], 1, 0, 
>> self.mapdigits, self.ceiling) 
>>                sum = sum + cost
>>                                                                              
>>      
>>            return sum
>>  
>>  where the containing class is a user class and self.ngram, r, and r.e are
>>  instances of extension types, the Python version runs, it would seem, 10
>>  times faster. I've looked a bit at the generated C code (attached) and 
>> didn't
>>  see anything obviously wrong; does anyone have any hints about what may be
>>  going on? I realize this is kind of a vague question but any pointers for
>>  further testing would be appreciated. Thanks in advance!
> 
> Perhaps the difference is that Python's eval loop special cases arithmetic
> operations on numeric types quite heavily, but the same loop in Pyrex has to
> resort to function calls?
> 

Huh? AFAICT, all of the operations on numeric types in the quoted code 
are being done in cdef'ed variables i, sum and cost. There is *some* 
overhead caused by converting i to a Python int, and by getting the 
result of the function call (Python float) into cost.

The guts of the operation is that big ugly function call ...
I'd suggest replacing that by "cost = 0.0" and running the comparisons 
again to get a baseline.

Cheers,
John