ボトルネックの計測
まずはどこが遅いか計測しよう。全体の時間の1%の処理を50%高速化しても、0.5%高速化したことにしかならない。
std::chronoを使うのがよいだろう。
シビアなケースでは計測結果をメモリ上に配置しておき、あとでまとめて標準出力やログファイルに出力するのがよいだろう。
無駄な処理をスキップ
無駄な処理を極限まで削ろう。
たとえば、1024バイトのデータを返す代わりに1バイトのデータを返せばすむような処理があるならそうしよう。
あるメモリから別のメモリにデータをコピーしている箇所があれば、ムーブできないか検討しよう。
２番目のメモリアロケートを省略できないか検討しよう。
メモリアクセス
ヒープメモリアロケートは遅いと肝に命じよう。
繰り返しヒープメモリアロケートしている場合は、アロケートが最初の１回のみで済ませられないか検討しよう。
適切なstdコンテナを利用しているか調べよう。
stdコンテナで機能が不足している場合は自作しよう。
ファイルアクセス
ファイルアクセスはヒープメモリアロケートに対してもはるかに遅い。
極力ファイルアクセスは避けよう。簡易データベースの利用も検討しよう。
フリーのファイルベースのデータベースとしてSQLiteやBerkeley DBがある。
排他処理の最適化
排他処理でリソースが１つの変数の場合はstd::atomicを利用しよう。
リソースが２つ以上の場合はstd::mutexでOKだが、本当にそれで良いか処理の設計自体を見直そう。
