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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4