[Effective Java] 67.최적화는 신중히 하라

최적화는 오히려 좋은 결과보다 해로운 결과로 이어지기 쉽다.

빠르지도 않고 제대로 동작하지도 않고 수정하긴 어려운 소프트웨어가 탄생할 수 있다.

 

빠른 프로그램보다는 좋은 프로그램을 작성하라

• 성능 때문에 견고한 구조를 희생하지 말자. (견고한 구조 - 내부 응집성이 높고 외부와 결합성이 낮은)
• 좋은 프로그램은 정보 은닉 원칙을 따라 개별 컴포넌트의 내부가 독립적으로 설계됨 → 나머지에 영향 주지않고도 각 요소를 재설계 가능 [아이템 15]
• 완성된 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 작성해야 해결 할 수 있기 때문에 설계 단계에서 성능을 반드시 염두에 두자.

 

성능을 제한하는 설계를 피하라

• 완성 후 변경하기 가장 어려운 설계 요소는 컴포넌트끼리, 또는 외부 시스템과의 소통 방식 ex) API, 네트워크 프로토콜 영구 저장용 데이터 포맷
• 이런 요소들은 완성후 변경이 어렵거나 불가능할 수 있음

 

API를 설계할 때 성능에 주는 영향을 고려하라

• public 타입을 가변으로 만들면 (내부 데이터 변경 가능), 불필요한 방어적 복사를 수없이 유발할 수 있음 [아이템 50]
• 컴포지션으로 해결 가능한 것을 상속으로 설계한 public 클래스는 상위 클래스에 영원히 종속되어 성능까지도 물려받게 됨 [아이템 18]
• 인터페이스가 있는데 굳이 구현 타입 사용하는 것도 구현체에 종속되어 성능까지 물려받게 됨 [아이템 64]
• 성능을 위해 API를 왜곡하지 말자 (성능 문제는 플랫폼이나 소프트웨어의 버전에 따라 사라질 수 있기 때문)

 

각각의 최적화 시도 전후로 성능을 측정하라

• 시도한 최적화 기법이 성능에 얼마나 영향을 줬는지 측정하라
• 프로파일링 도구를 사용하여 최적화 노력을 어디에 집중해야하는지 도움을 받자
• JMH : 프로파일러는 아니지만 자바 코드의 상세한 성능을 잘 보여주는 마이크로 벤치마킹 프레임워크

 

자바의 성능 모델

• 자바의 덜 정교한 성능 모델은 기본 연산에 드는 상대적 비용을 덜 명확하게 정의하고 있음 → 최적화로 인한 성능 변화를 예측하기 어려움
• 자바의 성능 모델은 구현 시스템, 릴리스, 프로세서마다 차이가 있음 → 최적화 효과를 각각 측정해야함 → 성능을 타협하게됨

 

결론

빠른 프로그램을 작성하려 안달하지 말자. (좋은 프로그램은 좋은 성능을 가져옴)

시스템을 설계할 때 성능을 염두에 두고, 구현을 완료했다면 성능을 측정해보라.

빠르지 않다면 프로파일러를 사용해 문제의 원인을 찾아 최적화를 해라. (변경 후 성능 측정 필수)