Item67. 최적화는 신중히 하라!
Intro
- 최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽다. 섣불리 진행하면 특히 그렇다.
- 빠르지도 않고 제대로 동작하지도 않으면서 수정하기는 어려운 소프트웨어를 탄생시킬 수 있다.
조언
빠른 프로그램보다는 좋은 프로그램을 작성하라
- 성능 때문에 견고한 구조를 희생시키지 말아야 한다.
- 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소 내부를 독립적으로 설계할 수 있다. 따라서 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다.
- 구현상의 문제는 나중에 최적화할 수 있지만, 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고는 해결 불가하므로 설계 단계에서 성능을 반드시 염두에 두고 임해야 한다.
성능을 제한하는 설계를 피하라
- 완성 후 변경하기가 가장 어려운 설계요소는 컴포넌트끼리나 외부 시스템과의 소통 방식이다.
- API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등이 대표적이다.
API를 설계할 때 성능에 주는 영향을 고려하라
- API는 완성 후 변경하기가 어렵다.
- public 타입을 가변으로 만들면, 내부 데이터를 변경할 수 있게 되어 불필요한 방어적 복사를 수없이 유발할 수 있다.
- 내부 데이터를 변경할 수 없게 만들자.
- 컴포지션으로 해결할 수 있음에도 상속 방식으로 설계한 public 클래스는 상위 클래스에 영원히 종속되며, 그 성능 제약까지 물려받게 된다.
- 상속이 아닌 컴포지션으로 만들자.
- 인터페이스도 있는데 굳이 구현 타입을 사용한다면, 특정 구현체에 종속되게 하여, 나중에 더 빠른 구현체가 나오더라도 이용 불가하다.
- 구현 타입이 아닌 인터페이스 타입으로 만들자.
성능을 위해 API를 왜곡하는 건 매우 안 좋은 생각이다.
- 잘 설계된 API는 보통 성능도 좋다.
- API를 왜곡시킨 성능 문제는 다음 버전에서 해결될 수 있으나 성능에 맞춰 API를 왜곡시키면 이를 지원하는데 큰 고통이 따른다.
깨끗하고 명확한 구조를 갖춘 프로그램을 완성한 이후 최적화를 고려하자
- 물론 성능에 만족하지 못한 경우에 한정한다.
각각의 최적화 시도 전후로 성능을 측정하라
- 시도한 최적화 기법이 성능을 눈에 띄게 높이지 못하는 경우가 많고, 심지어 나빠지게 할 때도 있다.
- 프로그램에서 시간을 잡아먹는 부분을 예측하기 힘들기 때문이다.
- 일반적으로 90%의 시간을 단 10%의 코드에서 사용한다.
- 프로파일링 도구는 최적화 노력을 어디에 집중해야 할지 찾는 데 도움을 준다.
- 개별 메서드의 소비 시간과 호출 횟수 같은 런타임 정보를 제공해준다.
- 자바 코드의 상세한 성능을 알기 쉽게 보여주는 마이크로 벤치마킹 프레임워크인 JMH도 있다.
- 최적화 시도 전후로 성능을 측정하는 것은 ‘추상화 격차’가 커서 최적화로 인한 성능 변화를 일정하게 예측하기 어려운 자바에서 특히 중요할 것이다.
핵심 정리
- 빠른 프로그램을 작성하려 안달하지 말자. 좋은 프로그램을 작성하자. 그럼 성능은 따라올 것이다.
- 시스템 설계 시, 특히 API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 설계 시 성능을 염두에 둬야 한다.
- 시스템 구현이 완료되었다면 성능을 측정해보자. 충분히 빠르다면 그것으로 끝이다.
- 느리다면 프로파일러를 사용해 문제의 원인을 찾고, 그 부분을 최적화하자.
- 알고리즘을 살펴보고, 변경하자. 알고리즘을 잘못 골랐다면 다른 저수준 최적화를 아무리 해봐야 소용 없다.
- 만족할 성능이 나올 때까지 이를 반복하고, 성능을 측정해 비교하자.
Comments powered by Disqus.