Python Developers Festa 2013.11 での発表資料です。 https://github.com/pyspa/pyfes/blob/develop/201311.rst 性能計測結果は Solaris 系の OpenIndiana 151a 上で実施したものですので、他の OS の場合は異なる傾向となる可能性もあります。
なんか指名されたので、 C vs Python vs Ruby vs Haskell(無意味な処理deベンチマーク) このコードを Pythonic に書き直していきます。 ちなみに、 Python は 3.3 を使います。 まず、最初のコード n = 4000 a = [] count = 1 for x in range(n): a.append([]) for y in range(n): a[x].append(count) count += 1 list(map(lambda e: e.reverse(), a)) print(a[-1][-1]) time コマンドで実行速度測ったら 5.1sec でした。 さて、 Python はローカル変数とグローバル変数でアクセス速度が違います。(呼び出した関数の中などからグローバル変数を書き換えられる可能性はありますが、ローカル変数は外
これは PyPy Advent Calendar の記事です。PyPyのコアディベロッパーである "Maciej Fijalkowski" 氏のブログ "Analysing python's performance under PyPy" の抄訳+αです。 Python の一般的なパフォーマン解析のモデルは、"プロファイラを実行して、ボトルネックを探し出し、それを最適化するか C で書き直す" ことです。しかし PyPy ではこのアプローチだけでは不十分です。なぜなら、 多くの大規模アプリケーションで、プロファイラはフラットです: PyPy のトランスレーションツールチェーン、Twisted、モダンな Web サーバ等が良い例です ボトルネックを発見したとしても、それが特定の関数内でのみ遅いのか、複数の関数が関係しているのか明確になるわけではありません。どうすれば遅くて、どうすれば速くなる
~$ python -m timeit -n 1000 "[x for x in range(1000) if x in range(500, 1500)]" 1000 loops, best of 3: 28.2 msec per loop ~$ python -m timeit -n 1000 "set(range(1000)).intersection(range(500, 1500))" 1000 loops, best of 3: 120 usec per loop リスト内包が約235倍時間かかりますね。リストをセットにするのも時間かからないので、合併や、交差は絶対 set() を使ったほうがいいですね。 Update range(500, 1500) を 1000回くらいよばれてしまっているので、一回呼び出すようにすると、 28.2msec が 18.2msec になった。ま
Pythonは最強ですね。文法はチョー簡単、ライブラリも充実度がすごい、それでいてメタプログラミングができる。そのメタプログラミングを使うと末尾再帰最適化までできるそうです…おそろしやNew Tail Recursion Decorator « Python recipes « ActiveState Code class tail_recursive(object): def __init__(self, func): self.func = func self.firstcall = True self.CONTINUE = object() def __call__(self, *args, **kwd): if self.firstcall: func = self.func CONTINUE = self.CONTINUE self.firstcall = False try:
ここ2〜3日、InfoPileのパフォーマンスチューニングをしており、ちょっともたつきを感じるような部分をほとんど解消することができた。InfoPileで使用した高速化テクニックの中で効果が大きく、よくつかわれそうなものを紹介しよう。尚、以下のスクリプトはPython 2.6.4で実行した。 listよりtupleを使う 可変長である必要のないシーケンスは、できるだけlistではなくtupleを使って構築しよう。listの生成/解放コストは意外と大きいのだ。 import time def run1(): for i in xrange(1000000): [i, i+1, i+2, i+3, i+4, i+5, i+6, i+7, i+8] def run2(): for i in xrange(1000000): (i, i+1, i+2, i+3, i+4, i+5, i+6, i+
http://groups.google.com/group/comp.lang.python/browse_thread/thread/314a3043ea63319f/ unicode vs s.decode unicodeはLOAD_GLOBALで、s.decodeはLOAD_ATTRでスタックに積まれる。で、LOAD_GLOBALの方が速い。 さらに言えば、何度もデコードを行うのであれば u = unicode のようにローカル変数にするとさらに速くなる。LOAD_ATTRやLOAD_GLOBALは最適化で消すことが出来ないので、明示的にローカル変数に束縛することはCPythonに限らず有効な手法だ。 'utf8' vs 'utf-8' 単なる1タイプの問題だけど、内部的には 'utf-8' が利用されており、 'utf8' を使うと 'utf-8' だと判断するのに1クッション必
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く