ITEM 67: 최적화는 신중히 해라

그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다. - 윌리엄 울프

자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. - 도널드 크누스

최적화를 할 떄는 다음 두 규칙을 따르라. 첫 번째. 하지 마라. 두 번째, (전문가 한정) 아직 하지마라. 다시 말해, 완전히 명백하고 최적화 되지 않은 해법을 찾을 때까지는 하지 마라. - M. A. 잭슨

최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽다.

빠른 프로그램 보다는 좋은 프로그램(견고한 구조)

빠른 프로그램 보다는 좋은 프로그램(견고한 구조)을 작성하는 것이 더 중요하다. ITEM 15 좋은 프로그램은 정보 은닉 원칙을 따라 개별 구성요소를 독립적으로 설계할 수 있고, 다른 요소에 영향을 주지 않고도 다시 설계할 수 있다. 아키텍처의 결함이 성능을 제한하는 상황이면, 시스템 전체를 다시 구현해야 할 수도 있다. 반드시, 설계 단계에서 성능을 고려해야 한다.

API 설계시 성능에 주는 영향을 고려해라

• ITEM 50 내부 데이터를 변경할 수 있게 만들면 불필요한 방어적 복사를 수없이 유발할 수 있다.

• ITEM 18 컴포지션으로 해결할 수 있음에도 상속 방식으로 설계한 클래스는 상위 클래스에 종속되며, 성능 제약까지도 물려받는다.

• ITEM 64인터페이스도 있는데 굳이 구현 타입을 사용하는 것은 좋지 않다.

최적화 시도 전후로 성능 테스트를 해라

최적화 시도가 성능을 눈에 띄게 높이지 못하는 경우가 많으며, 심지어 더 나빠지는 경우도 있다. 일반적으로 90%의 시간을 10%의 코드에서 사용하는 경우가 많으며, 프로그램에서 그 부분을 찾아내는 것이 쉽지 않다.

프로파일링 도구는 개별 메서드의 소비 시간과 호출 횟수와 같은 런타임 정보를 제공해, 어느 부분이 최적화가 필요한지 파악하는데 좋다.

• https://taetaetae.github.io/2019/05/12/got-of-java-seminar/

jmh는 프로파일러는 아니지만 자바 코드의 상세한 성능을 알기 쉽게 보여주는 마이크로 벤체 마킹 프레임 워크다. 자바는 작성된 코드와 CPU에서 수행하는 명령 사이의 격차가 커서 최적화로 인한 성능 변화를 예측하기가 어려우므로 반드시 전후로 성능 테스트가 필요하다.