Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Patterns - An Optimization Anecdote

python.org

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Python Patterns - An Optimization Anecdote

#41

Post by scott_s »

teoruiz wrote: post #27
RyanMcGreal wrote: post #21

Why not just: def f(list): return ''.join([chr(l) for l in list])

It is actually slower. Adding an f8 function using the ''.join() method: sikanda-13:30:02:/tmp$ python f.py [...] f1 0.07 f2 0.12 f3 0.07 f4 0.06 f5 0.09 f6 0.04 f7 0.02 f8 0.07 Original code linked in the article: http://www.python.org/doc/essays/f.py

My results agree with yours, in terms of who wins. Python 2.6 (2.4 is similar, and 3.0 is as well, for the techniques that were still valid) on OSX 10.5, Intel Core Duo at 2 GHz:

  [scotts@silver]$ /opt/local/bin/python2.6 f.py
  f1 0.107
  f2 0.19
  f3 0.106
  f4 0.097
  f5 0.139
  f6 0.073
  f7 0.025
  f8 0.103
edit: I added a ninth function,

  def f9(list):
    return ''.join(map(chr, list))
To test if the difference between f8 and f6 was the list comprehension or the joinfields method. A result of 0.072 tells me it's the list comprehension. The only difference between f8 and f9 is list comprehension versus map. That leads me to conclude that map is indeed a faster way to construct a list than a list comprehension. (Although this may change for a user-defined function. I could test this, but I've spent enough time already.)

Re: Python Patterns - An Optimization Anecdote

#42

Post by riffraff »

edanm wrote: post #33
riffraff wrote: post #7

Earlier quoted context omitted.

you can lookup once and inline the method, and only keep a flag to check if you need to invalidate that. Pypy & other jits al do this kind of things all the time :) But you don't need a jit: you can partially execute the code and determine that no changes were happening in the referenced globals, thus the inlining becomes possible. There is quite a bit of literature on the issue of using partial evaluation for optimi…

Interesting. What are the best sources for learning what kind of optimizations are actually implemented in practice in Python?

well neither of the above, in standard python, but the pypy project has _a lot_ of interesting stuff http://codespeak.net/pypy/dist/pypy/doc/extradoc.html

Re: Python Patterns - An Optimization Anecdote

#44

Post by dish »

zephyrfalcon wrote: post #24
RyanMcGreal wrote: post #21

Why not just: def f(list): return ''.join([chr(l) for l in list])

Because it's an old article. Admittedly, there's no easy way to know this, because it has no date, but believe me, it's been around for ages. At the very least, it predates the silly str.join method (and new-style classes and string methods altogether). However, before that, there was the string module, which had the join() function. This article probably relates to it in some way; I think that either it predates str…

WTF, Guido wrote that!? I will jump out of a window now.

Re: Python Patterns - An Optimization Anecdote

#45

Post by dish »

dish wrote: post #20
nene wrote: post #16

I decided to try writing the same thing in JavaScript and discovered something really strange. My first idea was: numbers.map(function(x){return String.fromCharCode(x);}).join(""); This was pretty fast already, but why not eliminate the anonymous function completely and pass String.fromCharCode directly to map(): numbers.map(String.fromCharCode).join(""); I timed it and... ...this was ~100 times slower than the previ…

That kind of should be the first train of thought in python too, why using "+" to add strings!? it maybe fixed in py3k but its still not worth it in py2.X return ''.join(map(chr, list)) Also the liberal use of the words list and string bothers me.

Since Guido invented the words "list" and "string" in python at least, I guess him using them doesn't bother me.
Post reply on HN