performance - パフォーマンスと読みやすさ

Question

この質問を読んで、私はこれを（引用符に注意してください）問題を解決するための「コード」として見つけました（ちなみにそれはperlです）。

100,{)..3%!'Fizz'*\5%!'Buzz'*+\or}%n*

明らかに、これは実際の（私の人生の実際のコードでは決して見られないことを望んでいる）意味のない知的例ですが、選択する必要がある場合、パフォーマンスのためにコードの可読性を犠牲にするのはいつですか？あなたは常識だけを適用しますか、それは常に最後の手段として行いますか？あなたの戦略は何ですか？

編集：申し訳ありませんが、私が質問をひどく表現したかもしれない答えを見て（英語は私の母国語ではありません）。コードを書いた後で初めてパフォーマンスと読みやすさを意味するのではなく、コードを書く前にも質問します。場合によっては、デザインを暗くしたり、クラスを暗くするプロパティを提供したりすることで、将来のパフォーマンスの向上を予測できます。コードを理解するのがはるかに困難になる場合でも、そのようなスレッドが提供するスケーラビリティを期待するため、複数のスレッドを使用するか、単一のスレッドのみを使用するかを決定できます。

score 28 · Accepted Answer

パフォーマンスが問題になる可能性がある状況に対する私のプロセス：

それを機能させます。
明確にしてください。
パフォーマンスをテストします。
意味のあるパフォーマンスの問題がある場合：速度をリファクタリングします。

これは、後の段階で変更するのがより難しい高レベルの設計決定には適用されないことに注意してください。

score 7 · Accepted Answer

私はいつも私が考えることができる最も読みやすいバージョンから始めます。パフォーマンスに問題がある場合は、リファクタリングします。読み取り可能なバージョンで一般化が困難な場合は、リファクタリングします。

重要なのは、リファクタリングが簡単になるように適切なテストを行うことです。

私は読みやすさをコードの一番重要な問題だと考えていますが、正しく機能するのはすぐそこです。

score 7 · Accepted Answer

読みやすさが最も重要です。最新のコンピューターでは、最も要求の厳しいアプリケーションの最も集中的なルーチンだけが、パフォーマンスについてあまり心配する必要があります。

score 5 · Accepted Answer

この質問に対する私のお気に入りの答えは次のとおりです。

機能させる
正しくする
速くする

物事の範囲では、コードの世話をしなければならない次の不運な愚か者を除いて、読みやすさについてがらくたを言う人はいません。ただし、そうは言っても...あなたが自分の芸術に真剣に取り組んでおり、これが芸術形式である場合は、コードを他の人が読めるようにしながら、できる限りパフォーマンスの高いものにするよう常に努力します。私の友人でありメンター (彼はあらゆる点で BADASS です) は、コードレビューで「愚か者は自分が理解できるコードだけを書き、天才は誰もが理解できるコードを書きます」と親切に教えてくれました。彼がどこからそれを手に入れたのかはわかりませんが、それは私に固執しています.

参照

score 4 · Accepted Answer

プログラムは、人々が読むことができるように、そして偶然にマシンが実行するためにのみ作成する必要があります。
— Abelson＆Sussman、SICP

適切に作成されたプログラムは、おそらくプロファイリングが容易であり、したがってパフォーマンスが向上します。

score 3 · Accepted Answer

あなたは常に最初に読みやすさのために行くべきです。システムの形状は通常、開発するにつれて進化し、実際のパフォーマンスのボトルネックは予想外になります。システムを実行していて、プロファイラーまたは他のそのようなツールによって提供される実際の証拠を見ることができる場合にのみ、最適化するための最良の方法が明らかになります。

「お急ぎの場合は、長い道のりを進んでください。」

score 3 · Accepted Answer

上記のすべてに同意するだけでなく、

最適化することを決定した場合:

構文の前にアルゴリズムの側面を修正します (たとえば、大きな配列でルックアップを行わないでください)。
あなたの変更が本当に物事を改善したことを証明し、すべてを測定してください
最適化についてコメントして、次の人がその関数を見て、元の場所に単純化しないようにします
結果を事前計算するか、より効果的に実行できる場所 (データベースなど) に計算を移動できますか?

実際には、できる限り可読性を維持してください。最適化されたコードであいまいなバグを見つけることは、単純で明白なコードよりもはるかに難しく、面倒です。

score 2 · Accepted Answer

私は常識を適用します-この種のことは、エンジニアリングに伴う無数のトレードオフの1つにすぎず、私が見ることができる特別な特性はほとんどありません。

しかし、より具体的には、パフォーマンスの名の下に奇妙な読めないことをしている圧倒的多数の人々は、時期尚早に、測定なしでそれらを行っています。

score 1 · Accepted Answer

パフォーマンスが必要であることが証明できない限り、パフォーマンスよりも読みやすさを選択してください。

score 1 · Accepted Answer

重要なパフォーマンスの問題が証明されている場合にのみ、パフォーマンスの可読性を犠牲にする必要があります。もちろん、「重要」とはそこにある落とし穴であり、重要なものとそうでないものは、作業しているコードに固有のものでなければなりません。

score 1 · Accepted Answer

1

「時期尚早の最適化はすべての悪の根源です。」-ドナルド・クヌース

于 2008-08-27T18:18:24.557 に答える

score 1 · Accepted Answer

読みやすさは常に勝ちます。いつも。そうでない場合を除いて。そして、それはめったにないはずです。

score 0 · Accepted Answer

最適化が必要な場合は、コンパクトさを犠牲にしてパフォーマンスの向上を維持したいと思います。perlには、簡潔さとパフォーマンスの比率を求めて、明らかに深みのあるものがありますが、コードを維持するためにやってくる人（私の経験では、通常6か月後の私）であるワンライナーを書くのと同じくらいかわいいです。）ここに記載されているように、拡張スタイルの何かを好むかもしれません：

http://www.perl.com/pub/a/2004/01/16/regexps.html

score 0 · Accepted Answer

時期尚早の最適化ルールには例外があります。たとえば、メモリ内のイメージにアクセスする場合、ピクセルの読み取りはアウトオブライン関数であってはなりません。また、イメージに対してカスタム操作を提供する場合は、次のようにしないでください。

typedef Pixel PixelModifierFunction(Pixel);

void ModifyAllPixels(PixelModifierFunction);

代わりに、外部関数がメモリ内のピクセルにアクセスできるようにします。そうしないと、いずれにせよ後でリファクタリングする必要がある低速のコードを作成することになり、余分な作業を行うことになります。

少なくとも、大きな画像を扱うことがわかっている場合はそうです。

performance - パフォーマンスと読みやすさ

14 に答える 14

Related

Reference