[Pyrex] Pyrex optimization chitchat

[Paul Prescod]

Phillip J. Eby wrote:

>> 
>> And I don't know if Greg cares much about performance issues. It 
>> obviously
>> was not his highest priority (which is good!).
> 
> 
> Well, the very first 'primes.pyx' example certainly emphasized speed.  

I guess that's sort of my fault. I never got back to Greg after this 
discussion ;)

http://mail.python.org/pipermail/python-list/2002-April/097644.html
http://mail.python.org/pipermail/python-list/2002-April/097661.html


> And, speed is the "other" reason for using Pyrex besides accessing C 
> libraries.  And, often, the reason for accessing a C library in the 
> first place is for speed...  So it seems that all the roads tend to end 
> back up at performance.  :)

Well obviously I'm interested!

> That's true.  I'm just also thinking that it would move Pyrex to a more 
> microkernel architecture, pulling its internal tables out into the 
> language itself.  At that point, the language's operators, allocation, 
> and so forth would all just be generics.

Interesting idea.

> Hm.  I don't think I'd want C++-style type conversions being applied, 
> though.  I'd rather say, e.g.
> 
> cdef dict foo = dict(bar)
> 
> instead of expecting Pyrex to convert 'bar' to a 'dict' on its own.

True.

> AFAIK, this is the way Python's headed anyway.  There was supposed to be 
> a warning about it added in 2.3, although there were some issues that 
> caused the warning to be dropped before the 2.3 final release.

Good point. But method calls are a little more fuzzy.

cdef x(list foo):
	foo.append(5)

Should the compiler expand that to optimized PyList_Append code or call 
a method by name? My rough instinct is that if the Pyrex programmer 
wants to short-circuit Python's method calling conventions they 
could/should do so explicitly like this:

from listoptimize import listappend

cdef x(list foo):
	listappend(foo, 5)

What do you think?

  Paul Prescod