-
ITEM 67 최적화는 신중히 하라
최적화 격언 세가지
- 맹목적인 어리석음을 포함해 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다(심지어 효율을 높이지도 못하면서)
- 전체의 97% 정도인 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다
- 최적화를 할 때는 다음 두 규칙을 따르라
- 첫번째 하지마라
- 두번째 전문가 한정 아직 하지마라. 다시말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라
- M. A. 잭슨
이 격언들은 자바가 탄생하기 20년 전에 나왔으며 최적화의 어두운 진실을 이야기한다
- 최적화는 좋은 결과보다 안좋은 결과가 나타나기 쉽다
- 잘못하면 빠르지도 않고 제대로 동작하지도 않으면서 수정이 어려워진다
성능 때문에 견고한 구조를 희생하지 말자 빠른 프로그램보다는 좋은 프로그램을 작성하라
- 좋은 프로그램인데 원하는 성능이 안나오면 그 아키텍처 자체가 최적화 할 수 있는 방법을 알려줄거다
- 좋은 프로그램이라면 정보은닉이 잘 되어 있을테니 다른 시스템에 영향을 주지 않고도 개별 요소를 다시 설계 가능하다
- 완성된 설계의 기본 틀을 바꾸다보면 구조가 쉽게 꼬이기 쉬우니 설계시 성능을 고려하여 개발하자
성능을 제한하는 설계를 피하라
- 완성 후 변경하기가 가장 어려운 설계 요소는 외부 시스템, 컴포넌트끼리의 통신이다
- API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등...
- 이런 설계 요소들은 완성후에는 변경하기 어렵거나 불가능할 수 있고 시스템 성능도 심각하게 제한 할 수 있다
API를 설계할 때 성능에 주는 영향을 고려하라
- public 타입을 가변으로 만들면, 즉 내부 데이터를 변경할 수 있게 만들면 불필요한 방어적 복사를 수없이 유발 할 수 있다
- 비슷하게 컴포지션으로 해결할 수 있음에도 상속 방식으로 설계한 public 클래스는 상위 클래스에 영원히 종속되며 그 성능 제약까지도 물려받게 된다
- 인터페이스가 있으니 구현타입을 사용하는것 역시 별로다
- 구현타입을 사용하면 특정 구현체에 종속되며 나중에 더 빠른 구현체가 나와도 이용하기가 힘들다
성능을 위해 API를 왜곡하는건 매우 안 좋은 생각이다
- API를 왜곡하도록 만든 그 성능 문제는 해당 플랫폼이나 아랫단 소프트웨어의 다음 버전에서 사라질 수 있다
- 하지만 왜곡된 API를 유지보수 할 때 계속 고통스러울거다
빠른 프로그램을 작성하려 안달하지 말자 좋은 프로그램을 작성하다 보면 성능은 따라 오게 마련이다
시스템을 설계할 때 특히 API, 네트워크 프로토콜, 영구 저장용 데이터 포맷을 설계할 때는 성능을 염두에 두어야 한다
시스템 구현을 완료했다면 이제 성능을 측정해보자 충분히 빠르다면 끝이다
충분히 빠르지 않다면 프로파일러를 사용해 문제의 원인이 되는 지점을 찾아 최적화를 수행하라
가장 먼저 어떤 알고리즘을 사용했는지 살펴보고 알고리즘을 잘 못 골랐다면 다른 저수준 최적화는 소용 없다
만족할 때까지 위 과정을 반복하고 모든 변경 후에는 성능을 측정하자