おかねをあならいずこの広告は、90日以上更新していないブログに表示しています。主張:高速化は最後のおたのしみにしましょう。無駄にいじいじして高速化させて満足し、結局その後はほとんど使わなかったなあ、、、が私の日常です。えらい人も言っていますが、高速化なんてホント最後でいいんです・・・。今まで何十回後悔したことか。(これからもまたやりますが。同じアルゴリズムでもざっくり100倍単位で簡単に高速化できます。このやり方ではpythonのインタープリターなゆるふわ△言語の良さを(該当コード部分において)捨ててしまいます。結局C/C++に魂を売っているだけです。コードの実行スピードが速くなっても生産性が下がれば、制作時間+コード実行時間は悪化していることがよくあります。私はほぼ確実に悪化できています。こんなデメリットもあるため、高速化は生産性をほとんど犠牲にしないで済むような段階、つまりできるだけ最後の段階でやるとお得になるわけです。この点において、numpyなどは実に良い粒度で魂を売ることに成功しているため、使用者は生産性をほとんど損なわずに高速化の恩恵を得ることができます。このバランスはとても素晴らしく、魂を売る者ならこの塩梅を目指すと良いでしょう。pythonの柔軟さを損なわずに)高速化するという、ゆるふわ△高速化をしてみます。pythonのfor文は遅いからダメだ、とかいう人がいますが、個人的にはその意見には同意しかねます。for文は悪者ではなく、for文内に遅いコードを書くことが悪いのです。forループだけを回した時間計測結果を下の方に書きましたが、pythonの他の処理に比べて遅いなんてことはないと思います。DataFrameがあったとします。ここでは、非常にややこしい条件分岐があるため、for文を使うことを選んだケースを想定しています。何かを計算するため、変数dfのa列を1行ずつ順番に取り出したくなったとします。(バックテストとかね。やつで自動で計測させています。若干オーバーヘッドがある気がして、数ms遅いかもしれません。キャッシュに関しては無視しています。キャッシュが効いたからこそ速かった場合もあるかもしれませんが、一旦はそれも実力(?)として比較しています。使用したバージョンはこれでした。0.22.0計測はそんなに速くないノートでやっているので時間は遅めです。pandas.Series型で、結構いかつめのオブジェクトです。よって計50万回も生成されるので、遅いメモリ確保がたくさん発生してそうです。内部で起きているindexの探索やら例外処理が重そうです。ほんのちょっとだけ負荷になってるかもしれません。殆ど作用しないようにした。影響が大きかったです。オーバーライドがいかついんでしょうか。内の処理が重いだけでした。.iloc(これは普通の関数呼び出し)も一個にまとめてみた。これは(b')とほとんど変わらず。負荷に比べると、関数呼び出しのコストは無視できるレベルですね。アクセスはどっちが速いのでしょうか。)よりもちょっと速いんですね。numpyに逃げる好例ですね。valuesでnumpy.arrayにしてからのindexingならほとんど生アクセスに近いので速いです。0.03秒(35ms)ちなみに空ループが以下のように35msでしたので、これがゆるふわ△高速化の限界値でしょう。