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. I tend > to use lots of explicit calculations, in order to make code easier to > understand. Things like adding/subtracting one, or calculating an offset > (for a struct, for instance) are common applications of this idiom, for > example: > > >>> p = a[(3*4+2)-1] # get the second byte of the third DWORD > > This kind of construct should be avoided. 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. Only when your finished program is too slow, you can start optimizing. First you use the profiler to find the 2% of your code that does all the slow work. Then you improve the algorithm. And if that didn't work, usually rewriting that small bit in C will be much more effective than saving a bytecode because of the order of the operands... -- Remco Gerlich
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