[아이템 67] 최적화는 신중히 하라 #37
Description
최적화는 신중히 하라
최적화는 좋은 결과보다 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇다.
다음을 항상 중시하라.
빠른 프로그램보다는 좋은 프로그램을 작성하라.
좋은 프로그램이지만 원하는 성능이 안 나온다면 아키텍처 자체가 최적화할 수 있는 길을 안내해줄 것이다.
구현상의 문제는 나중에 최적화해 해결할 수 있지만, 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고서는 해결하기 어렵다.
따라서 설계 단계에서 성능을 반드시 염두에 두어야 한다.
- 성능을 제한하는 설계를 피하라.
- 완성 후 변경하기가 가장 어려운 부분은 컴포넌트끼리, 외부 시스템과의 소통 방식이다. (API, 네트워크 프로토콜, 영구 저장용 데이터 포맷)
- API를 설계할 때 성능에 주는 영향을 고려하라.
- Public 타입을 가변으로 만들면 불필요한 방어적 복사를 수 없이 유발할 수 있다. 비슷하게 컴포지션으로 해결할 수 있음에도 상속 방식으로 설계한 Public 클래스는 상위 클래스에 영원히 종속되며 그 성능 제약까지 물려받게 된다.
성능을 위해 API를 왜곡하는 건 매우 안 좋은 생각이다.
잘 설계된 API는 성능도 좋은 게 보통이다. 가령 성능이 안 좋다해도 추후 업데이트가 될 것이지만 왜곡한다면 이를 지원하는 데 따르는 고통은 영원할 것이다.
신중하게 설계하여 명확하고 멋진 구조를 갖춘 프로그램을 완성한 다음에야 최적화를 고려하라.
최적화 규칙
- 하지 마라.
- 아직 하지 마라.
- 각각의 최적화 시도 전후로 성능을 측정하라.
- 시도한 최적화가 성능에 별 차이가 없는 경우가 많다. 심지어 더 나빠지게 하는 경우도 있다.
정리
빠른 프로그램을 작성하려 안달하지 말자. 좋은 프로그램을 작성하다 보면 성능을 따라오게 마련이다. 시스템 설계 시 외부 또는 영구 저장용, 데이터 포맷을 설계할 때는 성능을 염두에 두어야 한다. 이후 성능을 측정하고 빠르다면 좋은 프로그램을 작성한 것이다. 알고리즘을 잘못 골랐다면 그 최적화는 아무리 해봐야 소용없다.