[이펙티브자바] Item 67. 최적화는 신중히 하라

 

빠른 프로그램을 작성하려 안달하지 말자.
좋은 프로그램을 작성하다 보면 성능은 따라오게 마련이다.

 

✔ 빠른 프로그램보다는 좋은 프로그램을 작성해야 한다.

성능 때문에 견고한 구조를 희생하지 말자.

좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있다.

따라서 시스템의 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다.

 

프로그램을 완성할 때까지 성능 문제를 아예 무시하라는 뜻은 아니다.

구현상의 문제는 나중에 최적화해 해결할 수 있지만, 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고는 해결하기 불가능할 수 있다.

 

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

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

이러한 설계 요소들은 변경이 어렵거나 불가능할 수 있으며 동시에 성능을 제한할 수 있어 염두에 두어야 한다.

 

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

public 메서드에서 내부 데이터를 변경할 수 있게 한다면 불필요한 방어적 복사를 유발한다.

또 컴포지션으로 해결할 것을 상속 방식으로 설계하게 되면 영원히 상위 클래스에 종속되고 성능까지 물려받는다.

즉, 더 빠른 구현 클래스가 나오더라도 이용하기 어려울 수 있다.

 

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

잭슨이 소개한 최적화 규칙은 '하지 마라', '(전문가 한정) 아직 하지 마라'이다.

여기에 하나 더 추가한다면 '각각의 최적화 시도 전후로 성능을 측정하라'이다. 

이유는 시도한 최적화 기법이 성능을 눈에 띄게 높이지 못하는 경우가 많고, 심지어 더 나빠지게 할 때도 있기 때문이다.

 

프로파일링 도구는 최적화 노력을 어디에 집중해야 할지 찾는 데 도움을 준다.

이런 도구는 개별 메서드의 소비 시간과 호출 횟수 같은 런타임 정보를 제공하여, 집중할 곳은 물론 알고리즘을 변경해야 한다는 사실을 알려주기도 한다.

프로파일러는 아니지만 jmh도 자바 코드의 상세한 성능을 알기 쉽게 보여주는 마이크로 벤치마킹 프레임워크이다.

 

최적화 시도 전후의 성능 측정은 C와 C++같은 전통적인 언어에서도 중요하지만, 성능 모델이 덜 정교한 자바에서는 중요성이 더 크다. 

 

💡 정리

• 빠른 프로그램을 작성하려 안달하지 말자. 좋은 프로그램을 작성하다 보면 성능은 따라오게 마련이다.
• 하지만 시스템을 설계할 때, 특시 API, 네트워크 프로토콜, 영구 저장용 데이터 포맷을 설계할 때는 성능을 염두에 두어야 한다.
• 시스템 구현을 완료했다면 이제 성능을 측정해보라. 충분이 빠르면 그것으로 끝이다.
• 그렇지 않다면 프로파일러를 사용해 문제의 원인이 되는 지점을 찾아 최적화를 수행하라.
• 가장 먼저 어떤 알고리즘을 사용했는지를 살펴보자. 알고리즘을 잘못 골랐다면 다른 저수준 최적화는 아무리 해봐야 소용이 없다.
• 만족할 때까지 이 과정을 반복하고, 모든 변경 후에는 성능을 측정하라.