プログラムの速さを測るときって、つい「とにかく早くしたい！」って頑張りがちだけど、ちゃんとした測定方法を使わないと、結果が全然あてにならないことがあるよね🥺💭
そんな話を聞いて、わたしも「え、それまじ？」ってびっくりしたんだけど、あるエンジニアさんがランダムデータでベンチマークしてたせいで数週間も無駄に手作業で組み立て言語（アセンブリ）を書き直しちゃったって話なんだ✨
ランダムデータで測ると何がヤバいの？🤔
普通、プログラムのスピードを測るときは実際に使うデータに近い状態でテストするのが鉄則だって。この人は最初、意味もわからずランダムなデータでベンチマークしてて、その結果を元に爆速化を目指してたの。
でもね、ランダムデータっていうのはCPUのキャッシュとか予測機能が全然うまく働かないから、実際の処理速度と全然違う結果が出ちゃうんだって😳💦
だから「速くなった！」と思っても、それはたまたまランダムなデータで動かしただけで、現実の使い方では意味がなかったというオチ💭
どんなところでハマったか教えて！🧠
この人は手でアセンブリを書いて、パフォーマンスが良くなるように頑張ってたのに、最後にちゃんと本物のデータで測ったら全然速くなってなかったんだって。
「うわー！」って感じだけど、わたしもたまにあるよ。たとえば、勉強の仕方を変えたのに模試の点数が変わらないとか…💦
この話でわかったのは、テストするデータの質がめちゃくちゃ大事ってこと。適当な数字やランダムな情報で測っても、意味ないんだなぁって思った✨
まとめ：ベンチマークはリアルなデータで！👌
だからもしプログラムの速さを調べるなら、絶対に実際に使うようなデータで測るのが正解。
それに、いくら頑張って高速化しても、間違った基準でやってたら努力がムダになっちゃうから、ちゃんとしたやり方を最初に確認することが超大事なんだよね💡
わたしみたいに「とりあえずやってみよう！」って気持ちも大事だけど、**測るときのデータ選びはしっかり慎重にしような！**って、この記事を読んでつくづく思ったよ🥺🌸
以上、ちょっとしたプログラミングの落とし穴のお話でした～🎀✨
はてな
コメント
クリス
ランダムデータでも、実際のデータに近い分布を使えば問題なさそうだね。 BMI2は役立ちそうだけど、AVXは複数処理できないなら微妙かも。 ULEB128は大きな数向けだけど、64bit上限なら9バイトで済むはず。
ハンナ
そんなに性能重視なら、CやC++、Rustに書き直した方がいいんじゃない？
