ポエムです。
### 対象読者:
このポエムは，次の方にお読みいただくことを前提に説明しています。
- 新人プログラマー
ざっくりいうとAtCoder問題の「実行時間制限」と「メモリ制限」です。
チューニング作業にも作業工数が掛かります、そして、チューニングは部分適用が難しいです。
適用する or 適用しない(STOP or GO)に落とし所がなりやすい。
よって最適化後の目標タイムを決めて作業をする。
推測せずにプロファイラで計測する
CPUプロファイラ、メモリプロファイラを取りボトルネックを確認。
後で使う可能性があるならば、実行証跡を保存しておくこと。
◆所感
※GUIとマルチプロセスはプロファイラがとりにくいーーー。。
- ミクロ…コード
- マクロ…アルゴリズム/並列化/ライブラリ/要求仕様の変更
| 手法 | メリット | デメリット |
|---|---|---|
| アルゴリズム | オーダーレベルでの改善 | 理解に一手間、引き継ぎ時に犠牲者が出やすい |
| ライブラリ | 作るのはその道の専門家、動作テスト保証済み | 配布時に一手間 |
| 並列化 | CPU律速/IO律速が高速化 | アムダールの法則の制約を受ける、メモリを生贄に捧げて性能を確保。メモリ律速がどうしようもない |
◆所感
体感プログラマーはミクロベースの最適化作業をしやすい職業だと思います。
眼の前にコード上の問題が提示されているのが理由かな。。
変更規模によりますがコード変更を伴うので、最終出力が既存の要求仕様と同じようになるように簡単なテストコードをまず書く。
◆所感
コード変更によるコード破壊が防げます。
処理速度改善しました、でもコードが壊れましたを避けたい。
これrefactoring関係で用語がありそうな希ガス。
書きかけ。PythonではGCのみLOHは.netとJavaが採用してるので、そのうち採用されるはず（希望的観測）