At 07:37 08/04/01 +0000, Remco Gerlich wrote: >Carlos Alberto Reis Ribeiro wrote in comp.lang.python: > > My personal conclusions are as follows. Please feel free to disagree > and/or > > clarify: > > > > 1) Avoid any unnecessary calculation, specially inside tight loops. > > (...) > >Premature optimization is one of the worst programming sins. > >You spend programmer time (figuring out which order to type it) and >readability (writing it (3*4+2)-1 is self-documenting) in order to get some >tiny speed plus that probably doesn't matter at all. I agree with you. Optimization needs discipline. It's a capital mistake to optimize without knowledge of what is worth to optimize. I also want to point out that the expression above was a over simplistic example; actual code would be better "self-documented" using constants or similar things. My intention was to point out that some constructs are unexpectedly slow. It's a common mistake, specially for people educated in languages such as C and Pascal. We tend to assume that this kind of expressions will be heavily optimized by the compiler, and as such, we pay no attention to this. For expressions that gets executed only once, you're right, there's no big deal. However, sometimes the expression gets calculated in the middle of a loop. It will have a impact on the overall speed. And worse, it may be hard to discover why, even after running the profiler. Let us say that we have such a loop, using a high speed construction such as map. For instance, HEIGHT = 10 WIDTH = 10 DEPTH = 10 z = map (lambda x: x * (HEIGHT * WIDTH * DEPTH), a) At first, you could think that there is nothing in this expression to optimize it. However, the expression above is about 68% slower than the direct calculation: z = map (lambda x: x * 1000, a) z = map (lambda x: x * 1000, a)
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