성능 때문에 견고한 구조를 희생하지 말자
빠른 프로그램보다는 좋은 프로그램을 작성하라
좋은 프로그램: 정보 은닉 원칙 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있다.
아키텍처의 결함이 성능을 제한하는 상황 → 시스템 전체를 다시 작성하지 않고는 해결하기 불가능할 수 있음
따라서, 설계 단계에서 성능을 반드시 염두에 두고 시작해야 함.
-
성능을 제한하는 설계를 피해라
- API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등의 설계 요소들은 완성 후에는 변경하기 어렵거나 불가능하다. 또한 시스템 성능을 심각하게 제한할 수 있다.
-
API를 설계할 때 성능에 주는 영향을 고려해라
- public 타입을 가변으로 만들어서 내부 데이터를 변경할 수 있게 만들면 불필요한 방어적 복사를 수없이 유발할 수 있다.
- 컴포지션으로 해결 가능한데도 상속 방식으로 설계한 public 클래스는 상위 클래스에 영원히 종속되며 그 성능 제약까지도 물려받는다.
- 인터페이스도 있는데 굳이 구현 타입을 사용하는 것 역시 좋지 않다. 특정 구현체에 종속되어, 더 빠른 구현체가 나와도 이용하지 못하게 된다.
-
java.awt.Component 클래스의 getSize 메서드
- 해당 API는 이 메서드가 Dimension 인스턴스를 반환하도록 가변으로 설계
- getSize를 호출하는 모든 곳에서 Dimension 인스턴스를 새로 생성함(방어적 복사 때문에)
- 수백만개 생성시 부담 가능성
→ 불변으로 만드는게 가장 이상적, getSize를 getWidth, getHeight처럼 기본 타입 값들을 따로 반환하도록 나누는 방법도 있음.
- API설계 결정의 폐해
-
각각 최적화 시도 전후로 성능을 측정하라
-
자바의 성능 모델은 정교하지 않고, 구현 시스템/릴리즈/프로세서 마다 차이가 있어서 각각 하드웨어 플랫폼에서 최적화의 효과를 측정해봐야 한다 (측정의 중요성)