パフォーマンスが重要な場合、JavaのString.format（）を使用する必要がありますか？

ログ出力などのために、常に文字列を構築する必要があります。JDKバージョンでStringBufferは、（多くの追加、スレッドセーフ）とStringBuilder（多くの追加、非スレッドセーフ）をいつ使用するかを学びました。

使用についてのアドバイスは何String.format()ですか？それは効率的ですか、またはパフォーマンスが重要なワンライナーの連結に固執する必要がありますか？

例えば醜い古いスタイル、

String s = "What do you get if you multiply " + varSix + " by " + varNine + "?";

整頓された新しいスタイル（String.format、おそらく遅い）、

String s = String.format("What do you get if you multiply %d by %d?", varSix, varNine);

注：私の具体的な使用例は、コード全体で何百もの「ワンライナー」ログ文字列です。彼らはループを含まないので、StringBuilderヘビー級です。String.format()特に興味があります。

私はテストする小さなクラスを書いて、2つのクラスのパフォーマンスが向上しました。5から6倍にしてください。

import java.io.*;
import java.util.Date;

public class StringTest{

    public static void main( String[] args ){
    int i = 0;
    long prev_time = System.currentTimeMillis();
    long time;

    for( i = 0; i< 100000; i++){
        String s = "Blah" + i + "Blah";
    }
    time = System.currentTimeMillis() - prev_time;

    System.out.println("Time after for loop " + time);

    prev_time = System.currentTimeMillis();
    for( i = 0; i<100000; i++){
        String s = String.format("Blah %d Blah", i);
    }
    time = System.currentTimeMillis() - prev_time;
    System.out.println("Time after for loop " + time);

    }
}

異なるNに対して上記を実行すると、どちらも線形に動作しますString.formatが、5〜30倍遅くなります。

その理由は、現在の実装でString.formatは、最初に正規表現を使用して入力を解析してから、パラメーターを入力するためです。一方、plusとの連結は、（JITではなく）javacによって最適化され、StringBuilder.append直接使用されます。

私はhhafezコードを取り、メモリテストを追加しました：

private static void test() {
    Runtime runtime = Runtime.getRuntime();
    long memory;
    ...
    memory = runtime.freeMemory();
    // for loop code
    memory = memory-runtime.freeMemory();

これは、「+」演算子、String.format、およびStringBuilder（toString（）を呼び出す）のアプローチごとに個別に実行するため、使用されるメモリは他のアプローチの影響を受けません。さらに連結を追加して、文字列を "Blah" + i + "Blah" + i + "Blah" + i + "Blah"にしました。

結果は次のとおりです（平均5回の実行ごと）：
アプローチ時間（ms）割り当てられたメモリ（長い）
'+'演算子747 320,504
String.format 16484 373,312
StringBuilder 769 57,344

文字列 '+'とStringBuilderは時間的に実質的に同じであることがわかりますが、StringBuilderはメモリの使用においてはるかに効率的です。これは、ガーベッジコレクターが '+'演算子の結果として生じる多くの文字列インスタンスをクリーンアップできないように、十分短い時間間隔で多くのログコール（または文字列を含む他のステートメント）がある場合に非常に重要です。

また、メッセージを作成する前に、ログレベルを確認することを忘れないでください。

結論：

1. StringBuilderを使い続けます。
2. 時間がない、人生が短い。

ここに示すすべてのベンチマークにはいくつかの欠陥があるため、結果は信頼できません。

誰もJMHをベンチマークに使用していないことに驚いたので、私は使用しました。

結果：

Benchmark             Mode  Cnt     Score     Error  Units
MyBenchmark.testOld  thrpt   20  9645.834 ± 238.165  ops/s  // using +
MyBenchmark.testNew  thrpt   20   429.898 ±  10.551  ops/s  // using String.format

単位は1秒あたりの操作数であり、多いほど優れています。ベンチマークソースコード。OpenJDK IcedTea 2.5.4 Java仮想マシンが使用されました。

したがって、古いスタイル（+を使用）の方がはるかに高速です。

古い醜いスタイルは、JAVAC 1.6によって次のように自動的にコンパイルされます。

StringBuilder sb = new StringBuilder("What do you get if you multiply ");
sb.append(varSix);
sb.append(" by ");
sb.append(varNine);
sb.append("?");
String s =  sb.toString();

したがって、これとStringBuilderを使用することの間にまったく違いはありません。

String.formatは、新しいFormatterの作成、入力フォーマット文字列の解析、StringBuilderの作成、それにすべてを追加してtoString（）を呼び出すため、はるかに重いです。

JavaのString.formatは次のように機能します。

1. フォーマット文字列を解析し、フォーマットチャンクのリストに分解します
2. これは、フォーマットチャンクを繰り返し、StringBuilderにレンダリングします。これは、基本的に、新しい配列にコピーすることにより、必要に応じてサイズを変更する配列です。これは、最終的な文字列を割り当てるサイズがまだわからないために必要です。
3. StringBuilder.toString（）は、内部バッファを新しい文字列にコピーします

このデータの最終的な宛先がストリームである場合（Webページのレンダリングやファイルへの書き込みなど）、フォーマットチャンクを直接ストリームにアセンブルできます。

new PrintStream(outputStream, autoFlush, encoding).format("hello {0}", "world");

オプティマイザがフォーマット文字列の処理を最適化するのではないかと思います。その場合、String.formatをStringBuilderに手動で展開して、同等の償却パフォーマンスを得ることができます。

上記の最初の答えを拡張/修正するために、実際にはString.formatが役立つ翻訳ではありません。
String.formatが役立つのは、ローカリゼーション（l10n）の違いがある日付/時刻（または数値形式など）を印刷するときです（つまり、一部の国では04Feb2009が印刷され、他の国ではFeb042009が印刷されます）。
翻訳では、ResourceBundleとMessageFormatを使用して、適切な言語に適切なバンドルを使用できるように、外部化可能な文字列（エラーメッセージなど）をプロパティバンドルに移動するだけです。

上記のすべてを見ると、パフォーマンスに関しては、String.formatと単純な連結のどちらを使用するかが優先されます。連結よりも.formatの呼び出しを確認したい場合は、必ずそれを使用してください。
結局のところ、コードは書かれたよりもずっと多く読み込まれます。

あなたの例では、パフォーマンスプローブはそれほど変わらないが、考慮すべき他の問題があります。つまり、メモリの断片化です。連結操作でも、一時的なものであっても新しい文字列が作成されます（GCに時間がかかり、作業が増えます）。String.format（）の方が読みやすく、断片化が少なくなっています。

また、特定のフォーマットを頻繁に使用している場合は、Formatter（）クラスを直接使用できることを忘れないでください（すべてのString.format（）が行うのは、使い捨てのFormatterインスタンスをインスタンス化することです）。

また、他に知っておくべきこと：substring（）の使用に注意してください。例えば：

String getSmallString() {
  String largeString = // load from file; say 2M in size
  return largeString.substring(100, 300);
}

その大きな文字列は、Javaの部分文字列が機能する方法であるため、メモリに残っています。より良いバージョンは：

  return new String(largeString.substring(100, 300));

または

  return String.format("%s", largeString.substring(100, 300));

2番目の形式は、同時に他のことを同時に実行する場合におそらくより便利です。

String.Formatは比較的高速であり、グローバリゼーションをサポートしているため、通常はString.Formatを使用する必要があります（ユーザーが読み取るものを実際に書き込もうとしている場合）。また、ステートメントごとに3つ以上の文字列を翻訳しようとする場合（特に文法構造が大幅に異なる言語の場合）は、グローバル化が容易になります。

何も翻訳するつもりがない場合は、Javaの組み込みの+演算子からへの変換を利用してくださいStringBuilder。または、JavaをStringBuilder明示的に使用します。

ロギングの観点からのみの別の視点。

このスレッドへのログオンに関連する多くの議論が見られるので、私の経験を答えに加えることを考えました。誰かが役に立つと思うかもしれません。

フォーマッターを使用したロギングの動機は、文字列の連結を回避することにあると思います。基本的に、ログに記録しないのであれば、文字列連結のオーバーヘッドが発生することは望ましくありません。

ログに記録したい場合を除き、実際に連結/フォーマットする必要はありません。このようなメソッドを定義したとしましょう

public void logDebug(String... args, Throwable t) {
    if(debugOn) {
       // call concat methods for all args
       //log the final debug message
    }
}

このアプローチでは、デバッグメッセージとdebugOn = falseの場合、cancat / formatterは実際にはまったく呼び出されません。

ただし、ここではフォーマッターの代わりにStringBuilderを使用する方が良いでしょう。主な動機は、それを回避することです。

同時に、各ロギングステートメントに「if」ブロックを追加したくないので、

• 読みやすさに影響します
• 単体テストのカバレッジを減らします-すべての行がテストされていることを確認するときに混乱します。

したがって、上記のようなメソッドを使用してロギングユーティリティクラスを作成し、パフォーマンスヒットやそれに関連するその他の問題を心配せずにどこでも使用することを好みます。

StringBuilderを含むようにhhafezのテストを変更しました。StringBuilderは、XPでjdk 1.6.0_10クライアントを使用して、String.formatより33倍高速です。-serverスイッチを使用すると、係数が20に下がります。

public class StringTest {

   public static void main( String[] args ) {
      test();
      test();
   }

   private static void test() {
      int i = 0;
      long prev_time = System.currentTimeMillis();
      long time;

      for ( i = 0; i < 1000000; i++ ) {
         String s = "Blah" + i + "Blah";
      }
      time = System.currentTimeMillis() - prev_time;

      System.out.println("Time after for loop " + time);

      prev_time = System.currentTimeMillis();
      for ( i = 0; i < 1000000; i++ ) {
         String s = String.format("Blah %d Blah", i);
      }
      time = System.currentTimeMillis() - prev_time;
      System.out.println("Time after for loop " + time);

      prev_time = System.currentTimeMillis();
      for ( i = 0; i < 1000000; i++ ) {
         new StringBuilder("Blah").append(i).append("Blah");
      }
      time = System.currentTimeMillis() - prev_time;
      System.out.println("Time after for loop " + time);
   }
}

これは劇的に聞こえるかもしれませんが、絶対数がかなり低いため、私はそれをまれな場合にのみ関連すると見なします。100万の単純なString.format呼び出しの4秒は、大丈夫です-ロギングまたはお気に入り。

更新：コメントでsjbothaが指摘したように、finalがないため、StringBuilderテストは無効.toString()です。

からString.format(.)への正しいスピードアップファクターStringBuilderは、私のマシンでは23（-serverスイッチ付きでは16 ）です。

これはhhafezエントリの変更バージョンです。文字列ビルダーオプションが含まれています。

public class BLA
{
public static final String BLAH = "Blah ";
public static final String BLAH2 = " Blah";
public static final String BLAH3 = "Blah %d Blah";


public static void main(String[] args) {
    int i = 0;
    long prev_time = System.currentTimeMillis();
    long time;
    int numLoops = 1000000;

    for( i = 0; i< numLoops; i++){
        String s = BLAH + i + BLAH2;
    }
    time = System.currentTimeMillis() - prev_time;

    System.out.println("Time after for loop " + time);

    prev_time = System.currentTimeMillis();
    for( i = 0; i<numLoops; i++){
        String s = String.format(BLAH3, i);
    }
    time = System.currentTimeMillis() - prev_time;
    System.out.println("Time after for loop " + time);

    prev_time = System.currentTimeMillis();
    for( i = 0; i<numLoops; i++){
        StringBuilder sb = new StringBuilder();
        sb.append(BLAH);
        sb.append(i);
        sb.append(BLAH2);
        String s = sb.toString();
    }
    time = System.currentTimeMillis() - prev_time;
    System.out.println("Time after for loop " + time);

}

}

forループ後の時間391 forループ後の時間4163 forループ後の時間227

これに対する答えは、特定のJavaコンパイラーが生成するバイトコードを最適化する方法に大きく依存します。文字列は不変であり、理論的には、各「+」操作で新しい文字列を作成できます。しかし、コンパイラはほぼ間違いなく、長い文字列を構築する際の中間ステップを最適化します。上記の両方のコード行がまったく同じバイトコードを生成することは完全に可能です。

実際に知る唯一の方法は、現在の環境でコードを繰り返しテストすることです。文字列を双方向で連結して、お互いにタイムアウトする方法を確認するQDアプリを作成します。

"hello".concat( "world!" )連結で少数の文字列を使用することを検討してください。他のアプローチよりもパフォーマンスが向上する可能性があります。

3つを超える文字列がある場合は、使用するコンパイラーに応じて、StringBuilderまたはStringのみの使用を検討してください。