¿Debo usar String.format () de Java si el rendimiento es importante?

Tenemos que construir cadenas todo el tiempo para la salida del registro, etc. Sobre las versiones JDK hemos aprendido cuándo usar StringBuffer(muchos apéndices, seguros para subprocesos) y StringBuilder(muchos apéndices, no seguros para subprocesos).

¿Cuál es el consejo sobre el uso String.format()? ¿Es eficiente o nos vemos obligados a mantener la concatenación de líneas simples donde el rendimiento es importante?

por ejemplo, feo estilo antiguo,

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

vs. nuevo estilo ordenado (String.format, que posiblemente sea más lento),

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

Nota: mi caso de uso específico son los cientos de cadenas de registro de 'una línea' en todo mi código. No implican un bucle, por lo que StringBuilderes demasiado pesado. Estoy interesado String.format()específicamente.

Escribí una clase pequeña para probar que tiene el mejor rendimiento de los dos y + viene antes del formato. por un factor de 5 a 6. Pruébelo usted mismo

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);

    }
}

Ejecutar lo anterior para diferentes N muestra que ambos se comportan linealmente, pero String.formates 5-30 veces más lento.

La razón es que en la implementación actual String.formatprimero analiza la entrada con expresiones regulares y luego completa los parámetros. La concatenación con más, por otro lado, se optimiza con javac (no con el JIT) y se usa StringBuilder.appenddirectamente.

Tomé hhafez código y añadido una prueba de memoria :

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

Ejecuto esto por separado para cada enfoque, el operador '+', String.format y StringBuilder (llamando a ToString ()), por lo que la memoria utilizada no se verá afectada por otros enfoques. Agregué más concatenaciones, haciendo que la cadena sea "Blah" + i + "Blah" + i + "Blah" + i + "Blah".

Los resultados son los siguientes (promedio de 5 ejecuciones cada uno):
Tiempo de aproximación (ms) Memoria asignada (larga)
Operador '+' 747 320,504
String.format 16484 373,312
StringBuilder 769 57,344

Podemos ver que String '+' y StringBuilder son prácticamente idénticos en el tiempo, pero StringBuilder es mucho más eficiente en el uso de la memoria. Esto es muy importante cuando tenemos muchas llamadas de registro (o cualquier otra declaración que involucre cadenas) en un intervalo de tiempo lo suficientemente corto como para que el recolector de basura no pueda limpiar las muchas instancias de cadenas que resultan del operador '+'.

Y una nota, por cierto, no olvide verificar el nivel de registro antes de construir el mensaje.

Conclusiones:

1. Seguiré usando StringBuilder.
2. Tengo demasiado tiempo o muy poca vida.

Todos los puntos de referencia presentados aquí tienen algunos defectos , por lo que los resultados no son confiables.

Me sorprendió que nadie usara JMH para la evaluación comparativa, así que lo hice.

Resultados:

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

Las unidades son operaciones por segundo, cuanto más, mejor. Código fuente de referencia . Se utilizó la máquina virtual Java OpenJDK IcedTea 2.5.4.

Entonces, el estilo antiguo (usando +) es mucho más rápido.

JAVAC 1.6 compila automáticamente su viejo estilo feo como:

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();

Por lo tanto, no hay absolutamente ninguna diferencia entre esto y usar un StringBuilder.

String.format es mucho más pesado ya que crea un nuevo formateador, analiza su cadena de formato de entrada, crea un StringBuilder, lo agrega todo y llama aString ().

El String.format de Java funciona así:

1. analiza la cadena de formato, explotando en una lista de fragmentos de formato
2. itera los fragmentos de formato, renderizándolos en un StringBuilder, que es básicamente una matriz que cambia de tamaño según sea necesario, copiando en una nueva matriz. esto es necesario porque aún no sabemos qué tan grande asignar la Cadena final
3. StringBuilder.toString () copia su búfer interno en una nueva cadena

Si el destino final de estos datos es una secuencia (por ejemplo, renderizar una página web o escribir en un archivo), puede ensamblar los fragmentos de formato directamente en su secuencia:

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

Especulo que el optimizador optimizará el procesamiento de cadenas de formato. Si es así, tiene un rendimiento amortizado equivalente para desenrollar manualmente su String.format en un StringBuilder.

Para expandir / corregir la primera respuesta anterior, no es la traducción con la que String.format ayudaría, en realidad.
Lo que String.format ayudará será cuando imprima una fecha / hora (o un formato numérico, etc.), donde haya diferencias de localización (l10n) (es decir, algunos países imprimirán 04Feb2009 y otros imprimirán Feb042009).
Con la traducción, solo está hablando de mover cualquier cadena externa (como mensajes de error y demás) a un paquete de propiedades para que pueda usar el paquete correcto para el idioma correcto, utilizando ResourceBundle y MessageFormat.

Mirando todo lo anterior, diría que, en cuanto al rendimiento, String.format vs.concatenación simple se reduce a lo que prefieres. Si prefiere mirar las llamadas a .format sobre la concatenación, entonces, por supuesto, vaya con eso.
Después de todo, el código se lee mucho más de lo que se escribe.

En su ejemplo, el rendimiento probalby no es muy diferente, pero hay otros problemas a considerar: la fragmentación de la memoria. Incluso la operación de concatenación está creando una nueva cadena, incluso si es temporal (lleva tiempo GC y es más trabajo). String.format () es simplemente más legible e implica menos fragmentación.

Además, si usa mucho un formato particular, no olvide que puede usar la clase Formatter () directamente (todo lo que String.format () hace es instanciar una instancia de Formatter de un solo uso).

Además, debe tener en cuenta algo más: tenga cuidado de usar substring (). Por ejemplo:

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

Esa cadena grande todavía está en la memoria porque así es como funcionan las subcadenas de Java. Una mejor versión es:

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

o

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

La segunda forma es probablemente más útil si está haciendo otras cosas al mismo tiempo.

En general, debe usar String.Format porque es relativamente rápido y admite la globalización (suponiendo que realmente esté tratando de escribir algo que lea el usuario). También facilita la globalización si está tratando de traducir una cadena versus 3 o más por declaración (especialmente para lenguajes que tienen estructuras gramaticales drásticamente diferentes).

Ahora, si nunca planea traducir nada, confíe en la conversión incorporada de Java de los operadores + StringBuilder. O use Java StringBuilderexplícitamente.

Otra perspectiva desde el punto de vista de registro solamente.

Veo mucha discusión relacionada con el inicio de sesión en este hilo, así que pensé en agregar mi experiencia en respuesta. Puede ser que alguien lo encuentre útil.

Supongo que la motivación de iniciar sesión con formateador proviene de evitar la concatenación de cadenas. Básicamente, no desea tener una sobrecarga de string concat si no va a registrarlo.

Realmente no necesita concat / formato a menos que desee iniciar sesión. Digamos si defino un método como este

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

En este enfoque, el cancat / formateador no se llama realmente si es un mensaje de depuración y debugOn = false

Aunque aún será mejor usar StringBuilder en lugar de formateador aquí. La principal motivación es evitar todo eso.

Al mismo tiempo, no me gusta agregar el bloque "if" para cada instrucción de registro desde

• Afecta la legibilidad
• Reduce la cobertura en mis pruebas unitarias, eso es confuso cuando quieres asegurarte de que cada línea se pruebe.

Por lo tanto, prefiero crear una clase de utilidad de registro con métodos como el anterior y usarla en todas partes sin preocuparme por el impacto en el rendimiento y cualquier otro problema relacionado con él.

Acabo de modificar la prueba de hhafez para incluir StringBuilder. StringBuilder es 33 veces más rápido que String.format con el cliente jdk 1.6.0_10 en XP. El uso del interruptor -server reduce el factor a 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);
   }
}

Si bien esto puede sonar drástico, considero que es relevante solo en casos raros, porque los números absolutos son bastante bajos: 4 s por 1 millón de llamadas simples de String.format es algo correcto, siempre que los use para iniciar sesión o me gusta.

Actualización: como lo señaló sjbotha en los comentarios, la prueba StringBuilder no es válida, ya que falta una final .toString().

El factor de aceleración correcto de String.format(.)a StringBuilderes 23 en mi máquina (16 con el -serverinterruptor).

Aquí está la versión modificada de la entrada hhafez. Incluye una opción de generador de cadenas.

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);

}

}

Tiempo posterior para el ciclo 391 Tiempo posterior para el ciclo 4163 Tiempo posterior para el ciclo 227

La respuesta a esto depende mucho de cómo su compilador Java específico optimiza el código de bytes que genera. Las cadenas son inmutables y, en teoría, cada operación "+" puede crear una nueva. Pero, su compilador seguramente optimiza los pasos intermedios en la construcción de cadenas largas. Es completamente posible que ambas líneas de código anteriores generen exactamente el mismo bytecode.

La única forma real de saber es probar el código de forma iterativa en su entorno actual. Escriba una aplicación QD que concatene cadenas de forma iterativa y vea cómo se agota el tiempo una contra la otra.

Considere usar "hello".concat( "world!" )para un pequeño número de cadenas en concatenación. Podría ser incluso mejor para el rendimiento que otros enfoques.

Si tiene más de 3 cadenas, considere usar StringBuilder, o simplemente String, dependiendo del compilador que use.