17

または、短い名前の関数は、長い名前の同じ関数よりも効率的ですか? なぜまたはなぜではないのですか？

個人的には、より効率的だと思いますが、気にするほど効率的ではありません。

4

5 に答える 5

29

これらの名前はマシン レベルでは問題にならないため、パフォーマンスに違いはありません。コンパイラはこれらの名前を処理するため、プログラムにまったく違いはありません。

関数名はラベルに変換される可能性があり (実行時のパフォーマンスには影響しません)、変数名はおそらくレジスタ参照またはスタック操作 (使用する名前とは無関係) に置き換えられます。このレベルでは、OS は名前ではなくメモリ アドレスを使用 (およびジャンプ) します。

于 2012-05-27T05:45:07.393 に答える
13

Longer symbol names might—ever so slightly—slow down compilation, but symbol length has no effect on execution time.

Some implementations of interpreters can be affected by symbol name length, but not most modern ones: they typically do a "compilation" step which removes symbol names from consideration, among other processing.

I used a 1972 HP desktop computer running interpreted BASIC. The user manual suggested use of short symbol names for speed—and to conserve memory.

于 2012-05-27T05:50:09.433 に答える
5

質問の文字に答えるために:長い名前を持つ関数は、それ自体を再帰的に呼び出す場合を除いて (まれに)、短い名前を持つ関数とまったく同じように効率的です。

質問の精神に答えるために (もちろん推測ですが):現代のコンピューターで実行されている大多数の現代言語のソース コードで長い識別子を使用するコードは、従来「解釈されている」と見なされていたものでさえ、短い識別子。

一般的な答えと、(まあ、やや不自然な)例外をさらに下に示します。

黒、白

コンパイル済み言語:シンボルは、コンパイル中にシンボル テーブルに追加されます。シンボル テーブルのサイズと複雑さは、コンパイルステップの実行時間に影響しますが、プログラム自体の実行時間には影響しません。

解釈された言語:記号はある種の解釈時間辞書に追加され、記号を見つけるのに必要な時間は、通常、n が記号の長さである O(n) の割合で変化します。

グレーの色合い

コンパイル済み言語:考えられる例外の 1 つとして、動的ローディングとイントロスペクションを使用します。たとえば、*nix 上の C では、関数を呼び出してdlopen()共有オブジェクトを開き、関数を呼び出してdlsym()そのオブジェクト内のデータまたはサブプログラムを名前で検索できます。これにより、オブジェクトのシンボル テーブルが名前で検索されます。これがプログラムの主要な部分である場合、プログラムはオブジェクトの長さに関して O(n) の複雑さになる可能性があります。ただし、実際には、このようなオブジェクトのロードは、初期化時にモジュラー ユニットまたはプラグインをロードするためにのみ行われ、ルックアップは実際にはあまり発生しません。もちろん、独自のプログラム内のシンボルの長さは実行時間には影響しません。

解釈された言語:現代の解釈された言語の大多数は、いくつかの深刻な最適化とトークン化を実行するため、最終的には、長い識別子または短い識別子を参照することは 100% 同等である可能性があります。ハッシュ、長さの制限などはすべて物事を単純化します。より長い識別子を解析するには余分な時間がかかります (最近のコンピューターではマイクロ秒単位の場合もあります)。言語によっては、プログラムが実行されるたびにこれが行われる場合がありますが、プログラムの実行ごとに最大1 回までです。多くのevals を実行するか、膨大な量の内省を行わない限り、問題は発生しないはずです。それでも、Pythonの場合、イントロスペクションはdictベースであり、dictハッシュを使用してキーを見つけるため、実行時間はシンボルの長さではなくシンボルの数に応じて増加します.

しかし、それはコンパイルされていますか、それとも解釈されていますか? 調べれば調べるほど、現在使用されている純粋に解釈された言語は少なくなります。コメントで Python について言及されていましたが、Python はソース コードをバイトコードにコンパイルし、内部的に識別子を完全な名前ではなくトークンで参照します。JavaScript エンジンは、特定の実装に応じて、非常によく似た処理を行います。80 年代の (ほとんどの) 8 ビット BASIC でさえ、プログラムがテキスト形式でメモリに保存されないように、トークン化の手順を実行しました (これにより、メモリと CPU サイクルの両方が節約され、3 MHz、64 KB のコンピュータでは大量に供給されませんでした)。 、しかし、簡単に解釈できる中間形式です。変数名は辞書に入れられ、それらを参照するためにトークン (通常はアドレス) が使用されます。プログラムをリストすると、表示のために効果的にトークン化が解除されます。

于 2012-05-27T14:31:52.317 に答える
1

これは、リリース バイナリの実行時のパフォーマンスを意味すると仮定すると、対象とするプラットフォームによって異なります。

たとえば、Symbian OS では、DLL の関数は序数を介して検索されるため、名前がバイナリの一部になることはありません。したがって、答えはノーです。ターゲット イメージに表示されないため、違いがないため、効率的ではありません。

于 2012-05-27T11:44:38.900 に答える
1

何に関して効率的ですか？実行時に使用されるメモリ、コンパイル時に使用されるメモリ、実行時に実行される計算、コンパイル時に実行される計算、実行可能ファイルのサイズ、または何か?

より長い識別子は、コンパイル時に魔法のように多くの計算とメモリを必要とします。また、デバッグ実行可能ファイルにはいくつかのシンボルが含まれているため、長い識別子はデバッグ実行可能ファイルのサイズに影響を与える可能性があります。

実行時の計算とメモリの使用に関しては、いいえ、識別子の長さは、前述の違いによる間接的な影響以外には影響しません。

于 2012-05-27T05:53:50.663 に答える