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" <arcejae...@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@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
R.M. ArceJaeger
Author/Publisher, Platypus Press
Contact: arcejae...@gmail.com
Website: http://rmarcejaeger.com
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
