[item63] String '+' 연산 성능은 개선된걸까

[jun108059]

• 질문 1) JDK 6에서 어떤 부분이 개선됐을까요?
• 질문 2) 이렇게 개선됐는데 왜 아직도 String '+' 연산은 엄청 느릴까요?

질문 1) JDK 6에서 어떤 부분이 개선됐을까요?

366p 마지막 문단
자바 6 이후 문자열 연결 성능을 다방면으로 개선했지만, …

책에는 자바6 이후 문자열 연결 성능을 개선했다고 되어있지만 아무리 찾아봐도 자바5 부터 String ‘+’ operator는 컴파일 시 StringBuilder(또는 StringBuffer)로 변환되도록 변경된 내용 밖에 찾지 못했습니다.

자바6에서 어떤 부분이 개선됐는지 궁금합니다 😭

출처 : JDK 5 docs : String

이것마저도 String ‘+’ 연산보다 객체 생성 비용과 메모리 사용을 줄일 수 있었지만, 문제가 해결되지는 않았습니다.

1. StringBuilder와 String Buffer는 기본적으로 초기 capacity가 16 characters로 설정되고, 이는 사이즈가 작아서 재할당으로 인한 추가 비용이 발생하기 쉽습니다.
2. loop를 돌 때 StringBuilder 객체가 반복적으로 생성되기 때문에 비효율적입니다.

추가적으로, JDK 9 버전 부터는 이를 개선하기 위해 StringConcatFactory 를 도입했습니다.

• 참고 : JDK 9 docs : StringConcatFactory

JDK8 버전과 JDK 11버전으로 각각 컴파일하여 바이트코드를 분석한 글을 참고하면 아래와 같습니다.

출처 : https://jerry92k.tistory.com/50

좌측 JDK8 버전은 반복문(L5) 안에서 NEW java/lang/StringBuilder를 통해 새로운 StringBuilder 객체를 생성하고, JDK11 버전은 StringConcatFatory.makeConcatWithConstants 메서드를 통해 처리하는 것을 알 수 있습니다.

질문 2) 이렇게 개선됐는데 왜 아직도 String '+' 연산은 엄청 느릴까요?

JDK 버전이 올라가면서 String ‘+’ 연산이 개선됐기 때문에 더이상 StringBuilder를 사용하지 않아도 된다는 의견은 어렵지 않게 찾아볼 수 있습니다.

• https://dzone.com/articles/string-concatenation-performacne-improvement-in-ja
• https://choichumji.tistory.com/135

그런데 제가 JDK 18 버전 기준으로 테스트해보니 여전히 큰 성능 차이를 확인할 수 있었습니다.

(10번 연산)

(1,000번 연산)

(50,000번 연산)

1,000번 50,000번 연산은 당연히 느려지겠지만, 적어도 10번 연산에서는 ‘+’ 연산에서도 내부적으로 StringBuilder를 생성해서 활용하기 때문에 성능 차이가 거의 없어야 할 것 같은데.. (실행할 때마다 차이는 있지만) 200배 이상 느린게 이상합니다.

(String ‘+’ 연산과 StringBuilder의 Bytecode 비교)

혹시나 하여 ByteCode를 확인해보아도 JDK 9 버전에 추가된 makeConcatWithConstants 메서드로 ‘+’연산을 처리하고 있었습니다.

이유를 아시는 분이 있다면 도와주세요!

[youngreal]

1. JDK 5이후 문자열 연결 성능을 다방면으로 개선한 부분

Java8에 추가된 StringJoiner클래스
https://futurecreator.github.io/2018/06/02/java-string-joiner/

Java7에는유니코드문자가 포함된 문자열 효율압축하는 StringBuilder.appendCodePoint()
https://www.geeksforgeeks.org/stringbuilder-appendcodepoint-method-in-java-with-examples/

등등.. 더많을것 같긴한데 다방면으로 문자열 연결 성능을 개선한 부분은 이런이야기들을 하는게 아닐까요?

2. 문자열 최적화가 StringBuilder보다 아직 느린이유

찾아본다고 찾아봤는데 아직도 정확한지는 잘 모르겠습니다.

StringConcatFactory는 JIT컴파일러가 문자열 연산을 최적화하는 것인데

문자열 연결에있어서 타입을 동적으로 확인할수밖에 없는경우, 중간에 정수연산이나(문자열연산에 숫자타입이 포함된다거나)

String이 아닌 다른객체가 섞여있다던지,JIT이 검사해야할 작업들이 많아진다면 문자열 최적화하는데에 있어 여전히 시간이 오래

걸릴수밖에 없는것 같아요.

도움이 되실수도 있을것 같아서 확실하진않지만 조금 찾아봤어요

https://lovejaco.github.io/posts/a-crash-course-in-just-in-time-compilers/

루프안에서 느릴 수 있는 이유에 대해

"루프 안에서 += 스텝은 하나의 연산만 수행하는 것처럼 단순해 보이지만 동적 타이핑 때문에 예상보다 많은 단계를 필요로 합니다.

arr 변수가 100 개의 정수로 이루어진 배열이라고 가정합시다. 일단 코드가 워밍업 되면 baseline 컴파일러는 함수의 각 오퍼레이션에 ​​대한 스텁을 생성합니다. 따라서 정수의 가산 연산(+=)을 처리하는 sum += arr [i]에 대한 스텁이 만들어집니다.

그러나 sum과 arr[i]를 정수로 보장하기 어렵습니다. 자바스크립트의 타입은 동적이기 때문에 이후의 루프에서 arr[i] 값이 문자열이 될 가능성이 있습니다. 정수의 더하기 연산과 문자열 연결(concatenation)은 다른 오퍼레이션이기 때문에 둘은, 다른 기계 코드로 컴파일 됩니다 "

문자열 연결중 숫자타입이나 String이 아닌 다른객체타입이 섞여있을때 느릴수 있는이유에 대해

"코드의 더 빠른 버전을 만들기 위해, 최적화 컴파일러는 몇 가지 가정을 해야 합니다.

예를 들어, 특정 생성자에 의해 생성된 모든 객체가 동일한 속성을 가지고 있고, 동일한 순서로 추가된 경우에는 이를 근거로 실행 절차를 좀 더 생략할 수 있습니다.

"JIT가 이것을 처리하는 방법은 여러 개의 baseline 스텁을 컴파일하는 것입니다. 코드 조각이 항상 같은 타입으로 호출되는 경우하나의 스텁만 만들어집니다. 만약 다형성인 경우, 해당 연산을 통해 나온 각각의 타입 조합들의 스텁이 만들어집니다.

이는 JIT가 스텁을 선택하기 전에 많은 질문을 던저야 한다는 것을 의미합니다."

"각 코드 라인은 baseline 컴파일러에 자체 스텁 집합이 있기 때문에 JIT는 코드 라인이 실행될 때마다 타입을 계속 확인해야 합니다. 그래서 루프를 반복할 때마다, 동일한 질문을 해야만 합니다."

"만약 JIT가 이러한 검사를 반복할 필요가 없다면 코드는 훨씬 더 빨리 실행될 수 있습니다. 이것이 최적화 컴파일러가 하는 일 중 하나입니다"

최적화 컴파일러에서는 전체 함수가 모두 컴파일 됩니다. 타입 검사는 루프 전에 발생하도록 이동합니다."

더 자세하게 이해하려면 컴파일러에대해 공부해봐야 이해할수있을것 같아요.. 맞는소리를 했는지도 잘 모르겠습니다

관련해서 아시는분이 계시다면 추가로 말씀주시면 좋을것 같습니다