最適化された方法はどれですか?

Which is optimized way?


質問 written by MAC @2012-07-28 09:16:31Z

: 6 : 6 : 302

簡単な質問かもしれませんが、私は混乱しています

どのコードが最適化されていますか? 使用する必要がありますか?

内部プロセスの違いは何ですか?

String str = editText.getText().toString();     
str =str.trim().toLowerCase();
textView.setText(str);

textView.setText(editText.getText().toString().trim().toLowerCase());
コメント 1

これは重要ではない種類のハイパーマイクロ最適化です。より読みやすいコードを使用してください。(しかし、私はダウンボッターではありません)-JBニゼット9:22に

written by @2012-07-28 09:22:08Z

コメント 2

私(代名詞)

written by Sa 12 @2012-07-28 16:56:56Z

回答 1 written by Dalmas @2012-07-28 13:30:37Z
4

すべてを1行に入れると、ステートメントを複数行に分割するよりも良いとは思わないでください。 一般に、Javaコンパイラは、どちらの場合でもまったく同じバイトコードを生成するのに十分なほどスマートです。 最新のコンパイラは、多くのマイクロ最適化を行います。

それらをコンパイルして違いがあるかどうかを確認し、コマンドjavap -cバイトコードを逆コンパイルしjavap -c

編集:

私はちょうどテストし、ここに結果があります:

String str = editText.getText().toString();     
str = str.trim().toLowerCase();
textView.setText(str);

にコンパイルします:

compiles to :

そして2つ目:

       0: aload_0       
       1: getfield      #7                  // Field textView:Landroid/widget/TextView;
       4: aload_0       
       5: getfield      #4                  // Field editText:Landroid/widget/EditText;
       8: invokevirtual #8                  // Method android/widget/EditText.getText:()Landroid/text/Editable;
      11: invokevirtual #9                  // Method java/lang/Object.toString:()Ljava/lang/String;
      14: invokevirtual #10                 // Method java/lang/String.trim:()Ljava/lang/String;
      17: invokevirtual #11                 // Method java/lang/String.toLowerCase:()Ljava/lang/String;
      20: invokevirtual #12                 // Method android/widget/TextView.setText:(Ljava/lang/CharSequence;)V
      23: return        

次の結果が得られます。

and the second one :

推測できるように、それらは同一です。 Javaコンパイラーは最初の例を最適化し、変数が役に立たないため完全に削除しました。

したがって、結論は、読みやすいコードを使用する必要があるということです。

回答 2 written by Chintan Raghwani @2012-07-28 09:23:17Z
2

[1] String strの作成はデバイスのメモリを占有しますが、 後で使用することもできます したがって、後で必要な場合は最適化されます。

[2]メモリを使用しないため、 単純に最適化されますが、後でこの文字列が必要な場合は、常にフェッチする必要があるため 、プロセスを完了するにはより多くのマシンサイクルが必要です。 。

コメント 1

理論的には、ヒープではなくスレッドスタックスペースのみを占有します。

written by ショーンオーウェン @2012-07-28 10:31:07Z

コメント 2

@スワン・パードン、説明できますか?わからなかった!

written by チンタンラグワニ @2012-07-28 10:32:24Z

コメント 3

違いはオブジェクト参照のみです。オブジェクト参照は、ヒープ上ではなくスレッドのスタック上に存在します。スレッドには既に固定スタックが割り当てられています。もっとメモリを消費するとは言えないと思います。

written by ショーンオーウェン @2012-07-28 12:03:43Z

コメント 4

@Swan、わかった、ありがとう。

written by チンタンラグワニ @2012-07-28 12:06:04Z

回答 3 written by Chirag @2012-07-28 09:35:47Z
1

ここでは、最初に出力を文字列変数に格納し、そのためにスペースを占有します。その後、出力を小文字に変換してtextviewに設定します。

2番目のオプションでは、変数に保存せずにtextviewに設定します。

したがって、2番目のオプションは、それ以上のコーディングで使用したくない場合に適しています。

回答 4 written by Hardik Nadiyapara @2012-07-28 09:47:05Z
1

最初の変数では追加の変数を使用し、2番目の変数よりも多くのメモリを使用します。 2番目の場合、メモリ効率の利点があります

コメント 1

両方ともまったく同じオブジェクトを割り当てます。

written by ショーンオーウェン @2012-07-28 10:32:04Z

回答 5 written by Ahmad @2012-07-28 09:26:03Z
1

さて、2番目は読みにくくなっていますが、メモリ効率が高いという利点があります。 オブジェクトに参照変数を割り当てないと、オブジェクトはガベージコレクションの対象となりやすくなります。

しかし、言うまでもなく、このような小さな最適化よりも読みやすさを優先する必要があります。

コメント 1

@Downvoter ... downvoteを正当化してください10:07

written by アフマド @2012-07-28 10:07:43Z

コメント 2

(私は自分自身に投票しませんでしたが、答えます。JVMはメソッド内で後でローカル参照が使用されない場合を把握し、参照先のガベージコレクションを可能にします。)

written by ショーンオーウェン @2012-07-28 10:30:37Z

コメント 3

まあ...ローカル変数がfrmスタックをポップアウトしたとき、オブジェクトだけがガベージコレクト可能になると思うので。メソッド呼び出しをチェーンし、参照が配置されている可能性がかなりあるため、オブジェクトがGCのために遅延します。

written by アフマド @2012-07-28 10:40:43Z

コメント 4

GCは、スタックフレームが破棄される前に、オブジェクト参照が使用されていないことを知ることができます。nerds-central.blogspot.co.uk/2012/04/…–

written by ショーンオーウェン @2012-07-28 12:06:42Z

コメント 5

私は下票を正当化する必要はありませんが、 説明できます 。あなたは間違っています。

written by マツマン @2012-07-30 17:28:15Z

回答 6 written by codetiger @2012-07-28 09:20:05Z
2

最初の変数では、追加の変数を使用していますが、2番目の変数よりも多くのメモリが必要です。