저는 항상 두 번째 방법 (GString 템플릿 사용)을 사용하지만, 여러분과 같은 매개 변수가 두 개 이상있을 때 ${X}더 읽기 쉽게 만들 수 있다는 것을 알기 때문에 그것들을 감싸는 경향이 있습니다.
이러한 방법에 대해 일부 벤치 마크 ( Nagai Masato 의 우수한 GBench 모듈 사용 )를 실행하면 템플릿이 다른 방법보다 빠르다는 것을 알 수 있습니다.
@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 ) {
'String adder' {
foo + bar + baz
}
'GString template' {
"$foo$bar$baz"
}
'Readable GString template' {
"${foo}${bar}${baz}"
}
'StringBuilder' {
new StringBuilder().append( foo )
.append( bar )
.append( baz )
.toString()
}
'StringBuffer' {
new StringBuffer().append( foo )
.append( bar )
.append( baz )
.toString()
}
}.prettyPrint()
내 컴퓨터에 다음과 같은 출력이 표시됩니다.
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
따라서 가독성과 속도가 유리하므로 템플릿을 권장합니다 ;-)
주의 : toString()GString 메소드 끝에 추가 하여 출력 유형을 다른 측정 항목과 동일하게 만들고 더 공정한 테스트로 StringBuilder만들고 StringBuffer속도면에서 GString 메소드를 능가하는 경우. 그러나 GString은 대부분의 경우 String 대신 사용할 수 있으므로 (Map 키 및 SQL 문에주의해야 함) 대부분의 경우 최종 변환없이 그대로 둘 수 있습니다.
이 테스트 추가 (댓글에서 요청 됨)
'GString template toString' {
"$foo$bar$baz".toString()
}
'Readable GString template toString' {
"${foo}${bar}${baz}".toString()
}
이제 결과를 얻습니다.
String adder 514
GString template 267
Readable GString template 269
GString template toString 478
Readable GString template toString 480
StringBuilder 321
StringBuffer 369
보시다시피 (말했듯이) StringBuilder 또는 StringBuffer보다 느리지 만 여전히 String을 추가하는 것보다 약간 빠릅니다.
그러나 여전히 훨씬 더 읽기 쉽습니다.
아래 ruralcoder의 의견 후 편집
최신 gbench, 연결을위한 더 큰 문자열 및 적절한 크기로 초기화 된 StringBuilder를 사용한 테스트로 업데이트되었습니다.
@Grab( 'org.gperfutils:gbench:0.4.2-groovy-2.1' )
def (foo,bar,baz) = [ 'foo' * 50, 'bar' * 50, 'baz' * 50 ]
benchmark {
'String adder' {
foo + bar + baz
}
'GString template' {
"$foo$bar$baz"
}
'Readable GString template' {
"${foo}${bar}${baz}"
}
'GString template toString' {
"$foo$bar$baz".toString()
}
'Readable GString template toString' {
"${foo}${bar}${baz}".toString()
}
'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()
준다
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()두 GString 테스트에 추가 된 테스트를 다시 실행해야 합니다. 내 실행에 따르면 그들은String adder. 내 생각에는 실행 한 테스트가 실제로 연결을 처리하지 않으므로 GString 개체를 만들고 참조를 저장하는 것입니다. 어느 시점에서StringBuilder필요한 경우 여전히 가장 빠릅니다String.