박싱은 무겁다. 기본 타입을 사용하자. & 충족되는 타입이 있다면 문자열은 피하자.
박싱은 무겁다. 기본 타입을 사용하자.
기본 타입과 박싱된 타입의 차이는
- 기본 타입은 값만 가지고 있으나 박싱 타입은 식별성을 갖는다.
- 기본 타입은 언제나 유효하지만 박싱 타입을 null을 가질 수 있다.
- 기본 타입이 박싱 타입보다 시간, 메모리 사용면에서 더 효율적이다.
- 기본 타입은 동등 연산자로 비교가 가능하지만 박싱은 기본타입으로 바꿔서 비교해야 한다. ( 기본/ 박싱을 비교하면 자동으로 박싱이 풀린다.)
이런 이유로 식별성을 갖거나 제네릭으로 사용하거나 null을 식별값으로 가져야만 한다면 사용을 고려해봄직 하다. 마지막으로 리플렉션을 통해 메소드를 호출할 때도 박싱된 타입을 사용해야 한다.
충족되는 타입이 있다면 문자열은 피하자.
문자열은 문자열이다. 다른 값을 표현하기 위한 수단으로는 부적합하다. 또한 혼합 타입을 대신하기에도 적절하지 않다. 정말 해당 타입인지, 값이 맞는지 파싱하고 검증하고 굉장히 손이 많이 간다. 당연히 오류 가능성도 커진다.
문자열 연결 (“” + “”) 은 피하자.
문자열 역시 + 연산자로 합칠 수 있다. 굉장히 편리하다. 문자열은 값 타입이 아니다. 문자열 연결을 본격적으로 사용하면 성능 저하를 면치 못할 것이다. 문자열 연결
연산자로 n개를 이으면 n^2에 비례햔다. 앞서 말한 듯 값 타입이 아니라 양 쪽 내용을 복사해서 새롭게 만들어야 한다. 차라리 StringBuffer, StringBuilder를 사용하자.
추가로 StringTokenizer, String.split()으로 문자열을 분할할 수도 있다. 이는 상황에 따라 속도가 다른데 StringTokenizer가 빠른 경우는
- Delimiter가 하나라면 Tokenizer
- Delimiter가 ascii 값이라면
- 순회하는게 아니라면
의 경우가 있다. 보통 tokenizer가 빠르다. split이 내부에서 정규 표현식을 사용해서 처리하기 떄문이다. 그러나
- Delimiter가 여러 개면 내부에서 여러 번 스캐닝 작업을 한다.
- 유니코드라면 색인이 느리다.
- hasMoreToken, nextToken을 호출하면 그 때마다 풀 스캔을 한다.
는 특징으로 tokenizer가 빠를 때도 있다.