Siempre opto por el segundo método (usando la plantilla GString), aunque cuando hay más de un par de parámetros como el que tiene, tiendo a ajustarlos ${X}porque creo que los hace más legibles.
La ejecución de algunos puntos de referencia (utilizando el excelente módulo GBench de Nagai Masato ) en estos métodos también muestra que la creación de plantillas es más rápida que los otros métodos:
@Grab( 'com.googlecode.gbench:gbench:0.3.0-groovy-2.0' )
import gbench.*
def (foo,bar,baz) = [ 'foo', 'bar', 'baz' ]
new BenchmarkBuilder().run( measureCpuTime:false ) {
// Just add the strings
'String adder' {
foo + bar + baz
}
// Templating
'GString template' {
"$foo$bar$baz"
}
// I find this more readable
'Readable GString template' {
"${foo}${bar}${baz}"
}
// StringBuilder
'StringBuilder' {
new StringBuilder().append( foo )
.append( bar )
.append( baz )
.toString()
}
'StringBuffer' {
new StringBuffer().append( foo )
.append( bar )
.append( baz )
.toString()
}
}.prettyPrint()
Eso me da el siguiente resultado en mi máquina:
Environment
===========
* Groovy: 2.0.0
* JVM: Java HotSpot(TM) 64-Bit Server VM (20.6-b01-415, Apple Inc.)
* JRE: 1.6.0_31
* Total Memory: 81.0625 MB
* Maximum Memory: 123.9375 MB
* OS: Mac OS X (10.6.8, x86_64)
Options
=======
* Warm Up: Auto
* CPU Time Measurement: Off
String adder 539
GString template 245
Readable GString template 244
StringBuilder 318
StringBuffer 370
Entonces, con la legibilidad y la velocidad a su favor, recomendaría usar plantillas ;-)
Nota: Si se agrega toString()al final de los métodos GString para que la salida escriba lo mismo que las otras métricas, y que sea una prueba más justa, StringBuildery StringBuffervencer a los métodos para GString velocidad. Sin embargo, como GString se puede usar en lugar de String para la mayoría de las cosas (solo debe tener cuidado con las claves de mapa y las declaraciones SQL), en su mayoría se puede dejar sin esta conversión final
Agregar estas pruebas (como se ha pedido en los comentarios)
'GString template toString' {
"$foo$bar$baz".toString()
}
'Readable GString template toString' {
"${foo}${bar}${baz}".toString()
}
Ahora obtenemos los resultados:
String adder 514
GString template 267
Readable GString template 269
GString template toString 478
Readable GString template toString 480
StringBuilder 321
StringBuffer 369
Entonces, como puede ver (como dije), es más lento que StringBuilder o StringBuffer, pero aún un poco más rápido que agregar Strings ...
Pero aún mucho más legible.
Editar después del comentario de ruralcoder a continuación
Actualizado a la última versión de gbench, cadenas más grandes para la concatenación y una prueba con un StringBuilder inicializado a un buen tamaño:
@Grab( 'org.gperfutils:gbench:0.4.2-groovy-2.1' )
def (foo,bar,baz) = [ 'foo' * 50, 'bar' * 50, 'baz' * 50 ]
benchmark {
// Just add the strings
'String adder' {
foo + bar + baz
}
// Templating
'GString template' {
"$foo$bar$baz"
}
// I find this more readable
'Readable GString template' {
"${foo}${bar}${baz}"
}
'GString template toString' {
"$foo$bar$baz".toString()
}
'Readable GString template toString' {
"${foo}${bar}${baz}".toString()
}
// StringBuilder
'StringBuilder' {
new StringBuilder().append( foo )
.append( bar )
.append( baz )
.toString()
}
'StringBuffer' {
new StringBuffer().append( foo )
.append( bar )
.append( baz )
.toString()
}
'StringBuffer with Allocation' {
new StringBuffer( 512 ).append( foo )
.append( bar )
.append( baz )
.toString()
}
}.prettyPrint()
da
Environment
===========
* Groovy: 2.1.6
* JVM: Java HotSpot(TM) 64-Bit Server VM (23.21-b01, Oracle Corporation)
* JRE: 1.7.0_21
* Total Memory: 467.375 MB
* Maximum Memory: 1077.375 MB
* OS: Mac OS X (10.8.4, x86_64)
Options
=======
* Warm Up: Auto (- 60 sec)
* CPU Time Measurement: On
user system cpu real
String adder 630 0 630 647
GString template 29 0 29 31
Readable GString template 32 0 32 33
GString template toString 429 0 429 443
Readable GString template toString 428 1 429 441
StringBuilder 383 1 384 396
StringBuffer 395 1 396 409
StringBuffer with Allocation 277 0 277 286
.toString()las dos pruebas GString adjuntas. Mi carrera muestra que luego se desempeñan casi igual queString adder. Supongo que la prueba que ha ejecutado en realidad no maneja la concatenación, por lo que solo crea un objeto GString y almacena las referencias.StringBuildersigue siendo el más rápido, sin duda, si lo necesitaStringen algún momento.GString"como está", en algún momento debe convertirse en verdaderoString(incluso para imprimirlo), por lo que el tiempo verdadero es el último conjunto. Al final, la legibilidad de lasGStringplantillas superaStringBuildercuando el tiempo es tan cercano, por lo que es discutible. :-)No estoy muy seguro de por qué la respuesta anterior debe ir a puntos de referencia, búferes de cadenas, pruebas, etc.
fuente
Reproduciendo la respuesta tim_yates en el hardware actual y agregando los métodos leftShift () y concat () para verificar el hallazgo:
El resultado muestra que concat () es la solución más rápida para una cadena pura, pero si puede manejar GString en otro lugar, la plantilla GString todavía está por delante, mientras que la mención de honor debe ir a leftShift () (operador bit a bit) y StringBuffer () con inicial asignación:
fuente