빠른 프로그램보다는 좋은 프로그램을 작성하자
좋은 프로그램이지만 원하는 성능이 나오지 않는다면 그 아키텍처 자체가 최적화할 수 있는 길을 제공한다. 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있다. 따라서 시스템의 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다.
좋은 설계를 하는 방법
- 성능을 제한하는 설계를 피하자. 완성 후 변경하기가 가장 어려운 설계 요소는 바로 컴포넌트끼리, 혹은 외부 시스템과의 소통 방식이다.
-> API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 - API를 설계할 때 성능에 주는 영향을 고려하라.
-> public 타입을 가변으로 만들면, 불필요한 방어적 복사를 수없이 유발할 수 있다.
-> 컴포지션으로 해결할 수 있음에도 상속 방식으로 설계한 public 클래스는 상위 클래스에 영원히 종속된다.
-> 인터페이스가 있는데 구현 타입을 사용하지 말자.
최적화 시도 전후로 성능을 측정하라
일반적으로 90%의 시간을 단 10%의 코드에서 사용한다. 즉, 성능 최적화 시도 이후에 성능이 개선이 미비하거나, 떨어지는 경우가 많다. 따라서 성능 최적화 이후에는 성능을 측정하는 것이 중요하다
프로파일링 도구
프로파일링 도구는 최적화 노력을 어디에 집중해야 할지 찾는 데 도움을 준다. 이런 도구는 개별 메서드의 소비 시간과 호출 횟수 같은 런타임 정보를 제공하여, 집중할 곳은 물론 알고리즘을 변경해야 한다는 사실을 알려준다.