Effective Java : 아이템 67. 최적화는 신중히 하라

아이템 67. 최적화는 신중히 하라

• 좋은 구조의 소프트웨어를 만들고, 필요하다면 최적화를 해라.
• 성능을 위해 견고한 구조를 희생하지 말자. 빠른 프로그램보다는 좋은 프로그램을 작성하라.
• 프로파일링 도구를 이용해 성능 병목 지점을 찾아서 해결하라. 
• 공개 API 설계 시, 성능에 주는 영향을 고려하라. 
  • public 가변 객체의 경우 불필요한 방어적 복사를 요구함 (최적화 관점)
  • Composition으로 해결가능한 것을 상속으로 해결할 경우, public 가변 객체의 단점을 그대로 안고 감. 
• 최적화 시도 전후로 성능을 측정하라.

 

 

요약

최적화를 할 때는 다음 두 규칙을 따라야한다. 

• 첫번째, 하지마라.
• 두번째, 아직 하지 마라. 다시 말해 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지마라. 

최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇다. 빠르지 않고, 제대로 동작하지 않으며, 수정하기도 어려운 소프트웨어를 탄생시키는 것이다. 

성능 때문에 견고한 구조를 희생시키지말자. 빠른 프로그램보다는 좋은 프로그램(견고한 프로그램 / 개발에 용이한 프로그램)을 작성하고, 성능 문제가 발생한다면 그 때가서 해결하면 된다. 

또한 좋은 프로그램은 '정보 은닉'의 원칙을 따르기 때문에 개별 구성요소의 내부를 독립적으로 설계할 수 있다. 즉, 성능이 문제가 되는 부분을 독립적으로 재구성 해볼 수 있다는 것이다.

 

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

• 가변 public 타입은 내부를 수정할 수 있다는 것이다. 멀티 쓰레드 환경에서 수정 가능한 객체들을 그대로 사용하는 것은 불완전하기 때문에 불필요한 방어적 복사를 유발할 수 있다. 
• 비슷하게 Composition으로 해결할 수 있음에도 상속 방식으로 설계한 public 클래스는 상위 클래스에 영원히 종속되며, 성능 제약까지도 물려받게 된다. 
• 인터페이스도 있는데 굳이 구현 타입을 사용하는 것은 좋지 않다. 특정 구현체에 종속되게 하여 나중에 더 빠른 구현체가 나오더라도 이용하지 못하게 된다. 

 

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

• 최적화를 시도했다면, 반드시 전/후 성능을 측정해야한다. 왜냐하면 최적화가 항상 성능 개선을 가져오는 것은 아니기 때문이다. 심지어 성능을 더 나쁘게 만들 수도 있다. 
• 성능을 측정할 때는 JMH 같은 프로파일링 도구를 이용해보자.