C++ならいろんなところでコンパイラが作られて、切磋琢磨でよりよいバイナリ作れるんだろう。
Delphiは油断してるとひどいバイナリ吐いてるなぁって感じた。
いや、ひどいバイナリは、ひどいソ－スを書くがゆえに作られるのだが、
読みやすく書いただけの部分とかは、最適化でなんとかなって欲しいものだ。

Delphiのプロジェクトのオプションに、最適化するかどうかのチェックボックスがあり、
はじめからオンにしていて、デバッグ中でもそれを外すことはまずない。
優秀な最適化を行うコンパイラだと、最適化をオフにしないとデバッグ中にソースを追えないが、
Delphiでソースを追えないなんて、これまであったかなかったか思い出せないほどない。
つまり、Delphiでの最適化なんて、チェック入れてもほとんど働いてないってことか。

などという話題を出したのは、はじめから最適化を期待して、
もっと速そうなコードを書けるのにあえて、読みやすさを重視したコードを書いた部分で、
ブレークポイントで止めてCPUウィンドウで覗いてみたから。
ブレークポイントを置いたときだけ自動でデバッグ用バイナリを吐くわけでもなさそうだし、
やっぱり速そうなコードを書けるときは、読みやすさを考慮せずに書くべきだな。

二種類のコードのどちらが速いかについては、実際に計測するのがあたりまえだが、
計測しなくてもあきらかにわかるものもあり、余計な代入が減っているとか、
冗長なコードの冗長部分をそのまま再現してるっていうのは、
Z80より後の機械語に触れる機会がなく、理解してないあたしでも見ればわかる。

.NETに触って以来、速そうなコードよりわかりやすいコードを書く方向に傾いていた。
速そうなコードを自分で書かかなくても、.NETが速いコードに変換してくれるから、
余計なことはするなとかいう記事がマイクロソフトのどこかに書いてあって、
Delphiだってさほど気にせずに自分なりの書き方をしていれば、
意味を変えない範囲での一番速いバイナリを吐いてくれると、根拠もなく信じてきた。

これまでの真魚でも、スピードが重要になりそうな部分では冗長なコードを書いたりしないで、
出来るだけ速そうな書き方をしてきたわけだから、
現時点でもっと速くしたいと感じる部分がこれ以上速くはならないけれども、
遅くても問題にならないような場所ならもっと速く出来そうな感じ。

速くしようとすると、間違ってちょっとばかり意味を変えちゃって、
よくバグを混入することがあるので、こういう作業は慎重にやりたい。

4320017862