6

多数の (100 を超える) パラメータを持つ have/use メソッドを使用すると、コンピューティング パフォーマンスの点で非効率的ですか?

保守性の観点から効率的という意味ではなく、「生の」コンピューティングパフォーマンスのみです:)

4

6 に答える 6

4

おそらく理論的には、Java は値渡しであるため、関数が呼び出されると、JVM はすべてのパラメーター値のコピーを作成し、そのコピーを関数に渡すため、パラメーターの数が変更されるポイントがある可能性があります。実行時間に無視できない影響があります。しかし実際には、可能な限り、これらのコピーは「浅い」コピーであり、参照に似ているため、実際にコピーを作成するのに費やす時間はほとんどありません。したがって、パフォーマンス時間に顕著な影響を与えるには、おそらく 100 をはるかに超えるパラメーターが必要になるでしょう。

いずれにせよ、このようなものの実行時間を考慮しても、時期尚早の最適化のように聞こえます。これがプログラムのボトルネックではないことはほぼ確実であるため、実際にスローダウンを引き起こしていることが確実になるまで、時間を費やす価値はありません。プログラムの速度が許容できないほど遅い場合は、速度低下の原因として考えられる他の原因を調べてください。

もちろん、おっしゃる通り「メンテナンス性」の問題もあります。1 つの関数に何百ものパラメーターが必要なのはなぜですか? カスタム オブジェクトの ArrayLists などの複雑なパラメーターですか、それとも単純な組み込みデータ型ですか? 後者の場合、それらをまとめて配列や ArrayLists などにパックすることを検討してみませんか? あるいは、関数を複数の関数に分割してみませんか? 現代のコンピューターは十分に高速であるため、多くの (おそらくほとんどの) 目的で、プログラマーの時間はプロセッサーの時間よりも価値があります。速い。

于 2012-12-07T18:21:10.320 に答える
3

以下の記事にあるように、パラメーターが少ないほどパフォーマンスが向上しますが、パフォーマンスが大幅に低下するわけではありません。ただし、オブジェクトを渡すことを検討する必要があります。

http://www.dailyfreecode.com/forum/parameter-performance-21574.aspx

于 2012-12-07T18:14:20.480 に答える
1

あなたの質問に答えるには: いいえ、100 個のパラメーターを渡しても、パフォーマンスが大幅に低下することはありません。別の答えとは異なり、オブジェクトを渡さないことをお勧めします。それを行うと、コードは保守できなくなります。誰も理解できないパラメータでいっぱいのマップを見てきました。代わりに、Effective Java で Joshua Block が推奨するベスト プラクティス (Chapter 7、メソッド シグネチャ) を使用して、パラメーターの数を妥当なレベルに抑えてください。

例: メソッドを複数のメソッドに分割します。

同様の質問に対するこの回答を参照してください。

多くの引数をメソッドに渡すためのベストプラクティス?

于 2012-12-07T18:17:17.403 に答える
1

まあ費用はかかります。これらのパラメータはすべてスタックにプッシュする必要があります。ただし、重いループでない限り、計算能力の面で問題が発生するとは思いません。

あなたは仲間のプログラマーに腹を立てていますか? または、ある種のプログラムで作成されたコードを作成しますか?

于 2012-12-07T18:14:04.643 に答える
0

私は現在、「Java: The Good Parts」というタイトルの本を読んでいます。一般的には、インターフェイスを渡すことをお勧めします。100 個のパラメーターを使用してインターフェイスを作成し、100 個のパラメーターを渡す代わりにそれを渡すことをお勧めします。今後何が起こるかは、より明確になるでしょう。

私に関する限り、最大のコストはそれを維持することです。しかし、これらのパラメーターを 1 回渡すだけでも大きな違いはありません。

于 2012-12-07T18:18:04.673 に答える
0

答えるのは難しいですが、ほとんどの人は、少数のメソッド パラメータが深刻な問題を示していると感じています。

ただし、考えてみると、多くのメソッドパラメーターがパフォーマンスに影響を与えることを示す側面もいくつかあります。各メソッド パラメータは、スタック上のスロットを占有します (ローカル変数のように)。スロット自体は基本的にほとんど無料ですが、メソッド モンスターを呼び出すときは、各パラメータ スロットにも値を設定する必要があります。つまり、呼び出し元がスロットの値を取得するための READ 操作と、その値のスタックへの PUSH が必然的に発生します。

そうです、各パラメーターには小さなコストが付随しており、最初の概算として、コストはパラメーターの数に比例します。

ここで、どこかからパラメーター値を取得すると、そのパラメーターへの参照を渡すだけでなく、より多くの作業を効果的に行うことができます。

public int area(int x1, int y1, int x2, int y2) {
     return ....;
}

それ以外の

public class Rectangle {
    int x1, y1, x2, y2;

    public int area() {
        return ....;
    }
}

最初のケースでは、4 つの int をプルしてスタックにプッシュする必要がありますが、2 番目のケースを呼び出すには、四角形への参照をプルするだけで済みます。確かに、rectangle の area() メソッドはそのメンバーをプルする必要がありますが、少なくとも 3 つのスタック プッシュを節約できました (100 個のパラメーターを使用すると、おそらくさらに節約できます)。

また、100 個のパラメーターを持つメソッドは、それが非常に大きなメソッドであることを意味します。そうしないと、ほとんどのパラメーターがとにかく使用されず、単に無駄になります。大規模なメソッドは複雑さが高いことを示唆しており、これは適切なコードを生成する JIT の機能を妨げる可能性があります。実証するのは難しいですが、簡単な例はメソッドのインライン化です。JIT には、インライン化の対象となるコードの量に制限があり、大きなメソッドは候補になりません。ある程度、JIT は一般的に使用される慣用句に最もよく対処することが期待できます (最も一般的なケースを最適化すると、明らかに労力がかかります)。

于 2012-12-07T18:32:59.907 に答える