平安京ビューの性能解析 cProfileを使ってみよう

git flowは中毒性があります. git flow featureを続けていくことが快感です.

Pythonのプロファイラは, cProfileというのが標準でついています. ストレージなど, システムの解析では, どこにボトルネックがあるのか見つけることがすでに難しいということが多く, それを見つけることがすでに技術なのですが, 平安京ビューは簡単です. さっさとcProfileを使ってみましょう.

1
$python -m cProfile one-layer-benchmark.py

まずは, 明らかに問題となっているN=1000の時を見てみます. 抜粋です. プロファイラなしの場合は10秒程度ですが, プロファイラをつけると24秒くらいかかります. このうち, set/get, copyI/copyJというところが合計で20秒程度とってることが分かります.

1
2
3
4
5
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 36140445    4.013    0.000    4.013    0.000 heiankyoview.py:113(set)
 36265385    3.795    0.000    3.795    0.000 heiankyoview.py:115(get)
    47086    5.540    0.000    9.087    0.000 heiankyoview.py:133(copyI)
    64503    6.287    0.000   10.350    0.000 heiankyoview.py:136(copyJ)

N=100の時も同様に採取してみます. set/getは, N=1000の時に36Mで, N=100の時に0.16Mですから, 10倍以上です. copyI/copyJは, N=1000の時に47kで, N=100の時に1kですから, こちらも10倍以上です.

1
2
3
4
5
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   166090    0.018    0.000    0.018    0.000 heiankyoview.py:113(set)
   170646    0.016    0.000    0.016    0.000 heiankyoview.py:115(get)
     1179    0.022    0.000    0.035    0.000 heiankyoview.py:133(copyI)
     1771    0.030    0.000    0.047    0.000 heiankyoview.py:136(copyJ)

実はこれらは, 平安京ビューが内部的に使っている二次元テーブルの更新処理です. ちょっと重すぎるなぁという印象です. copyI/copyJというのは, ある列(行)を別の列(行)にまるまるコピーする操作です. 内部的に使っている二次元のTableクラスを, C言語で実装された二次元配列クラスに置き換えて高速化出来るかも知れません. あるいは, アルゴリズム自体をいじるか. 影響の少なくて, 将来的に負債にならなそうなものからやりましょう.

以上です.