プログラミング/python の履歴(No.1)

更新

公開メモ

プロファイリング†

python は普通に書くと思った以上に遅いことになる場合が多いので、 プロファイリングの結果を基に重い処理を numpy 側に移したりするのが役に立つ

以下では jupyter 上でのプロファイリングを想定

基本†

%%prun -s cumulative -l 40
# ここに処理を書く

などとしてプロファイリング結果を見られる

  • ただし、この %%prun はセルの先頭に無いとダメ
  • %%prun の下に import を書いて、そこで reload が走るとそれまでカウントされてしまう 
     - import は別セルで行うべき

UI 処理を走らせてはいけない†

プロファイリング中に print や、画面のスクロールなど、UI の更新処理が入ると、 メイン処理と並列して UI スレッドが走ることになり、プロファイラが混乱するようだ。

このとき実時間 cumtime を　メインのスレッド と UIスレッドで分け合う形になるので、

並列で UI スレッドが走っているとメインのスレッドの cumtime がその分だけ「「短くなる」」

というおかしな結果が出る。

確認方法†

        19687877 function calls (19687873 primitive calls) in 71.616 seconds

  ncalls  tottime  percall  cumtime  percall filename:lineno(function)
       1    0.006    0.006   71.639   71.639 {built-in method builtins.exec}
       1    0.000    0.000   71.633   71.633 <string>:1(<module>)

のように cumtime 順に並べたときにトップに <string>:1 のようなのが来て、 その cumtime が実時間とほぼ一致していることが重要。

そうでないときは UI スレッドに cumtime を取られているので、正しい解析ができない

Counter: 108 (from 2010/06/03), today: 9, yesterday: 4