[Effective Java] 아이템67 - 최적화는 신중히 하라

개인적으로 명심하고 싶은 내용이었다. :smile:

(맹목적인 어리석음을 포함해) 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다. (심지어 효율을 높이지도 못하면서)

(전체의 97% 정도인) 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다.

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

성능 때문에 견고한 구조를 희생하지 말자. 빠른 프로그램보다는 좋은 프로그램을 작성하자. 구현상의 문제는 나중에 최적화해 해결할 수 있지만, 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고는 해결하기 불가능할 수 있다. (아키텍처를 잘 구현해 놓고, 세부적으로 튜닝을 하자)

성능을 제한하는 설계를 피하라

완성 후 변경하기 가장 어려운 설계 요소는 바로 컴포넌트끼리, 혹은 외부 시스템과의 소통 방식이다.

• API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등이 대표적이다.
• 이러한 요소들은 완성 후에 변경하기 어렵거나 불가능할 수 있다.

API 설계할 때 성능에 주는 영향을 고려하라

• public 타입을 가변으로 만들면, 불필요한 방어족 복사를 수없이 유발할 수 있다.
• 컴포지션으로 해결할 수 있음에도 상속 방식으로 설계한 public 클래스는 상위 클래스에 영원히 종속되며 그 성능 제약까지도 물려받게 된다.

예를 들어 Dimension 인스턴스를 생각해보면, width 와 height 변수가 public 으로 선언되어 있어 가변이다. 따라서 getSize 메서드에서 방어적 복사를 하면서 인스턴스를 항상 새로 생성해주고 있다.

@Transient
public Dimension getSize() {
    return new Dimension(width, height);
}

최적화 시도 전후로 성능을 측정하라

시도한 최적화 기법이 성능을 눈에 띄게 높이지 못하는 경우가 많고, 심지어 더 나빠지게 할 때도 있다. 주요 원인은 우리 프로그램에서 시간을 잡아먹는 부분을 추측하기가 어렵기 때문이다.

프로파일링 도구는 최적화 노력을 어디에 집중해야 할지 찾는데 도움을 준다. 다양한 프로파일링 도구를 정리해둔 포스팅이 있어 기록한다.

jmh도 언급해둘만한 도구다. 자바코드의 상세한 성능을 알기 쉽게 보여주는 마이크로 벤치마킹 프레임워크다. 나중에 한번 실습을 해보는 것도 좋겠다. https://github.com/openjdk/jmh