Item 67. 최적화는 신중히 하라 #65
Description
Chapter : 9. 일반적인 프로그래밍 원칙
Item : 67. 최적화는 신중히 하라
Assignee : heon118
🍑 서론
최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇다.
빠르지도 않고 제대로 동작하지도 않으면서 수정하기는 어려운 소프트웨어를 탄생시킬 수 있다.
🍑 본론
빠른 프로그램보다는 좋은 프로그램을 작성하라.
: 아키텍처 수준에서의 성능 최적화를 위해 가독성이 좋고, 재사용성이 높고 수정이 용이한 코드를 작성하라.
- 프로그램의 아키텍처가 잘 설계되어 있으면, 개별 구성 요소의 성능 문제는 대체로 구성 요소 내부의 개별적인 최적화를 통해 해결할 수 있다.
- 좋은 프로그램은 정보 은닉 원칙을 따라 개별 구성요소의 내부를 독립적으로 설계할 수 있으므로 영향을 주지 않고 각 요소를 재 설계할 수 있다.
- 아키텍처의 결함이 성능을 제한한다면 시스템 전체를 다시 작성해야할 수 있으므로 설계 단계가 중요하다.
성능을 제한하는 설계는 피하라.
- 성능에 큰 영향을 미치는 설계 요소들은 신중하게 결정해야 한다.
- 컴포넌트 간의 소통 방식이나 외부 시스템과의 연결 방식 같은 핵심적인 설계 요소들은 한 번 결정되면 추후에 변경하기 어렵기 때문에 초기 설계 단계에서 성능을 고려하여 결정해야 한다.
- API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등은 완성 후 변경하기 어렵거나 불가능할 수 있으며, 동시에 시스템 성능을 심각하게 제한할 수 있기에 초기 설계에서 신중히 결정해야 한다.
API를 설계할 때 성능에 주는 영향을 고려하라.
- public 타입을 가변으로 만들면 불필요한 방어적 복사를 유발할 수 있다.(item 50)
- 메모리 사용이 증가하고, 프로그램 성능이 저하될 수 있다.
- 가능하면 불변 객체를 사용하여 이러한 문제를 방지하고, 필요한 경우에만 가변 객체를 사용하자.
- 컴포지션으로 해결할 수 있는 경우에도 상속을 이용하면 상위 클래스에 영원히 종속되고, 성능에 제약까지 물려받는다.(item 18)
- 상속은 코드의 재사용성을 높이지만, 상위 클래스의 특성을 물려받아 변경이 어렵다.
- 반면, 컴포지션을 이용하면 필요한 부분만을 선택하여 클래스를 구성할 수 있어, 유연성이 높아지고 성능 최적화에 유리하다.
- 인터페이스가 아닌 구현 타입을 사용하면, 차후 개선된 구현체를 사용하기 어려워진다.
- 클래스보다 인터페이스를 이용하면 코드의 유연성을 높이고, 성능 최적화에 좋다.
성능을 위해 API를 왜곡하지 마라.
- API 왜곡은 장기적으로 API의 사용성을 저하시키고 유지보수를 어렵게 만든다.
- 기술의 발전으로 성능 문제는 자연스럽게 해결될 수 있지만, 일단 왜곡된 API는 수정이 어렵고 관리의 어려움이 지속될 수 있다.
API 왜곡(API distortion)은 API(Application Programming Interface) 사용 시 발생하는 다양한 형태의 비정상적인 동작이나 성능 저하를 의미합니다.
각각의 최적화 시도 전후로 성능을 측정하라.
- 최적화 후, 성능을 눈에 띄게 높이지 못하는 경우가 많고, 더 나빠질 때도 있다.
- 프로그램에서 시간을 잡아먹는 부분을 추측하기 어렵기 때문에 짐작한 부분이 성능에 별 영향을 주지 않는다면 시간낭비다.
- 일반적으로 90%의 시간을 단 10%의 코드에서 사용한다.
- 따라서 프로파일링 도구를 활용해 최적화 노력을 어디에 집중해야 하는지 찾아보고 최적화를 진행하자.
🍑 결론
최적화할 생각하지 말고 설계나 잘해라