Which happens first?

[Carlos Alberto Reis Ribeiro]

At 12:54 08/04/01 -0400, Steve Holden wrote:
>This sin is also known as "introducing implementation bias". Imagine how
>silly you will feel if you spend several days optimizing a large Python
>suite in this way, then changes in the compiler technology render your code
>even less efficient than it would have benn if written naturalistically.

My intention was to point out that some pretty common optimizations are not 
done by the Python compiler, and, as a result, people from a specific 
background could have a hard time figuring out why some constructs are 
slower than they "should" be, at least in their minds. Ok, it is something 
that is completely "implementation biased". However, the fact is that 
*lots* of people come from the C/C++/Pascal background, and as such we tend 
to use some idioms that are not efficient when implemented in Python.

Anyway, I apologize if I made it look like another thread on silly 
optimization techniques. We all know how important is to identify the 
hotspots inside the program *before* doing any optimization. On the other 
hand, I believe that a lot of people may share the same perception that I 
had, and it would be nice to know it beforehand - to avoid some silly (and 
unexpected) speed loss.

As for your last remark, I think that fully documented expressions is a 
very natural way of writing programs. Instead of writing the final value, 
you leave the documentation of how did you arrive to it explicit on the 
code, by means of intermediate expressions. In this sense, I believe that I 
was trying to write it the most natural way possible, but unfortunately, 
the compiler is not helping me <wink>.

>If speed matters as much as Carlos seems to feel it does then arguably
>Python isn't the right language in the first place! Of course, as
>suggestions for how the compiler might do a better job they are fine, but
>I'm sure the developers would be happier to see patches than suggestions.

Good point, and it's well taken. Just that sometimes Python seems to be the 
perfect language to do what I want. I just want it to be a little bit 
faster :-)

>Yup. First, make it work. THen (if it doesn't work fast enough) make it work
>faster.

I agree... but I keep thinking that, *in this particular case*, we could do 
it a little better (and faster).


Carlos Ribeiro