[Tutor] Python Extensions in C

[Rachel-Mikel ArceJaeger]

I suppose it's up to the programmer. Personally, I find something like this:

variable += something

a lot easier to read than

temp = something
variable += temp

For me, it's just another variable I have to worry about allocating/deallocating/seeing if it's used anywhere else/accidentally using when I shouldn't.

And I'm sure you're right and the memory tweaks I mentioned aren't that necessary. I only brought them up because James asked about memory management and depending on the program you're using and the size of your inputs, it actually can make a difference. I recall one program I wrote where changing things little things like division and eliminating extra variables that we don't think of as being time-expensive drastically lessened the runtime.

Rachel


On May 26, 2011, at 10:40 AM, Alan Gauld wrote:

> "Rachel-Mikel ArceJaeger" <arcejaeger at gmail.com> wrote
> 
>> avg = sumall / count;
>> return avg;
>> Just return sumall/count instead.
>> Then you don't have to waste a register or assignment operation.
> 
> Readibility counts in C too. And premature optimisation is even
> more of an evil since C is harder to read to start with....
> This code doesn't need to be saving microseconds (the Python
> object creation will likely consume far more resource and
> speed than these tweaks).
> 
>> Division is expensive. Avoid it when you can.
> 
> That is entirely dependant on your processor.
> Even on an Intel chip with a math processor it's
> only very slightly more expensive than the other operators,
> compared to memory allocation it's lightning fast.
> And readability counts.
> 
>> for (a=0; a != count; a++) {
>>           temp = PyFloat_AsDouble(PySequence_Fast_GET_ITEM(seq,a));
>>           sumall += temp;
>> Again, save variables and operations. Write this as:
>> 
>> for (a=0; a != count; a++) {
>>                     sumall += PyFloat_AsDouble(PySequence_Fast_GET_ITEM(seq,a));
> 
> Again the two Python calls will vastly outweigh the savings.
> And in combining the lines you lose a debug and instrumentation
> opportunity and the chance to introduce a safety check of
> the return values. Reliable code beats fast code.
> 
>> It's cheaper when you're using powers of two to just
>> right or left-shift: >> or <<. Since you want to increase
>> by a power of two, do:
>> 
>> (avg - PyFloat_AsDouble(PySequence_Fast_GET_ITEM(seq,a) << 1;
> 
> While this is sufficiently idiomatic to be understood by
> most C programmers it's still likely to be swamped in effect
> by the Python calls. Readibility still counts, make the
> code express the algorithm not the workings of the CPU.
> 
> C can be tweaked to be unreadable or it can be made as
> clear as most other 3GLs. The more unreadable it is the
> more likely it is to harbour bugs. If there is a genuine need
> to be as small and fast as possible then optimise, but hide
> those optimisations in a function if possible. If there is no
> need to optimise at the expense of readability or reliability
> then don't.
> 
> Consider these the ravings of an ex maintenance programmer
> who spent far too much of his life deciphering other folks
> "clever" C code... It wasn't clever and it wasn't working!
> 
> Alan G.
> 
> 
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor

R.M. ArceJaeger
Author/Publisher, Platypus Press

Contact: arcejaeger at gmail.com
Website: http://rmarcejaeger.com