[Carlos Alberto Reis] > ... > My intention was to point out that some constructs are unexpectedly > slow. But they're also "unexpectedly dynamic", and the two are hard to separate. Let's zoom ahead to the example: > ... > 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) Note that the latter *may* compute something entirely different than the original, so it's not a safe optimization. The problem is that we don't know what's in a, so we don't know what the "*" in "x *" means either: it could invoke any code whatsoever (via coercion and/or operator overloading gimmicks) at runtime, including code that reaches into the module and changes the bindings for any or all of HEIGHT etc. The language is defined in such a way that HEIGHT etc are looked up fresh on each iteration. Of course it's rarely good practice to exploit that, but Python doesn't forbid it. Heck, we generally can't even know what "map" means at compile-time (the names of builtins are not reserved, and sometimes people even change their bindings in the __builtin__ module!). the-point-to-wysiwyg-isn't-machine-efficiency-ly y'rs - tim
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