여기서는 StringBuffer클래스의 성능을 올리는 방법에 대하여 알아보도록 하자.
일반적으로 StringBuffer는 dafault크기로 시작하여 새로운 스트링이나 문자값이 
입력되었을 경우, 버퍼에 계속 추가시키는 단계를 반복한다.

J2SDK 1.3버전에서는 이 StringBuffer클래스의 초기크기를 16으로 시작하게끔 설계해놓았다. 
이 크기는 StringBuffer의 한도가 초과되는 시간에 버퍼가 증가(새로 append되었을시)
하기 위해 필요한 크기의 2배만큼이다.

즉 2배씩 증가한다는 것이다. 이 경우네는 버퍼의 내용을 좀 더큰 버퍼측으로 복사하는
일을 반드시 해야 한다.

결국 여기서 StringBuffer의 크기를 예상하여 효과적으로 적용시켜준다면, 
list를 string형태로 변환하는데 있어서 Standard API를 이용할 경우 최소 3배이상, 
local cache를 이용할 경우 최소 2배이상의 성능을 보장할수 있게 된다.

샘플코드를 보도록 하자.

    public class GrowDemo {
        static final int N = 1000000;
        static final String str = "testing";
    
        public static void main(String args[]) {
            StringBuffer sb = new StringBuffer();
            file://StringBuffer sb = new StringBuffer(N * str.length());
    
            long start = System.currentTimeMillis();
            for (int i = 1; i <= N; i++) {
                sb.append(str);
            }
            long elapsed = System.currentTimeMillis() - start;
            System.out.println(elapsed);
        }
    }

위의 예제는 N개의 스트링을 버퍼안에 추가시키는 것을 100만번의 루프로 테스트하였다.
여기서는 각각의 스트링에 대한 길이를 알고 있기때문에 버퍼의 최적화되어진 크기를
계산하여 초기화시킬수 있을것이며, 이 경우는 버퍼가 한계값을 초과하여 복사와 
재할당되어지는 일을 미연에 방지할수 있을것이다.

위의 프로그램의 결과값을 아래와 같이 나올것이다.

테스트 

 Intel P-III 500, RAM 256, OS : Windows 2000 pro

1> 사이즈를 정하지 않은 경우

1521 milli second

2> 사이즈를 정한후 테스트

531 milli second

위의 기록을 보더라도 최소한 2배의 성능차이를 보이는 것을 알수 있다.

 

Article report :


 

이러한 기술을 "downside"라 부른다. 만약 프로그램 작성시 버퍼의 크기가 얼마나 
커야될지를 모른다면 예상치 버퍼의 크기보다 조금 더 큰 사이즈를 할당해 주는 것이 좋다. 
어차리 나중에 버려지게 될 메모리 영역이기 때문이다.
큰 버퍼크기를 다루는 것도 아주 중요한 일이 될수 있다는 것을 알아야 한다.

이러한 같은 기술상황하에서도 서로 다른 상황을 고려해볼수도 있다.
데이터구조에서의 최종 크기를 프로그래머가 직접 알고 있다면 아예 그 크기를 클래스의 
생성자에서 명시해주는 것도 생각해 볼수 있는 것이다.