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