"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
