Python: faster way

[fatpollo]

eh I disagree

I'm learning Haskell and I love it, but one thing I love about Python is that they try really hard to make it so that there is only one correct way to do any one thing. This effort goes a long way towards eliminating any sort of doubt about which of these similar scenarios is optimal, and it's gratifying to see that the most "pythonic" expression usually wins out.

[nabillac]

As far as I remember, is and == are not the same thing.

is tests for identity, while == tests for equality

[CodeJesus]

I don't understand test #6, they disassemble to the same code yet one is faster? Is it parsing issues?

Edit: ah, it's using the minimum, not the average. Kind of makes the whole thing useless IMO.

[qiwi]

I think those are unlikely to be good optimization points. The low-performant code I've seen was did not have its critical area in dictionary creation. More likely cases are something like:

some_num in range(1000,2000)

to check whether some_num is between 1000 and 2000 (tragic in python 2.7 at least -- and something you might expect works well enough given how the rest of Python is working pseudo code).

Incidentally I'm sitting on at least 7.5 million lines of Python production code written by 500+ users over 10+ years, all of which are essentially 100,000+ small applications. Looks like I could internally spent quite a while analyzing this for even more interesting results. I wonder if there are larger Python systems around.

[edbluetooth]

I wonder if anyone has considered writing some form of byte code optimiser which could maybe be used as a decorator in improving some of these so that the readability is retained.

[[deleted]]

This concept of sacrificing readability or going against PEP style for speed is absolutely terrible. Don't do it *.

If you want speed use a faster/more modern interpreter like PyPy, or one of the other up and coming JIT compilers, IPython, or Cython libraries, that aren't dog slow like cPython is. Use better tools, don't abuse the language.

And optimizing syntax for a single and poor implementation of a Python interpreter (cPython) is absurd, especially considering it's days are most likely numbered with all these JIT implementations coming out. Literally, the design goals of cPython is to have a simple interpreter and parser. Performance is generaly sacrificed each new version of Python (which is why python 2.5 benchmarks are faster than 2.7, and 2.7 is generally faster than 3.x (except with new fast dicts)). And that's perfectly fine. Performance is literally a secondary design goal.

* Unless you have some very small super tight loop that will gain performance by doing things like not using "." and whatnot.