Search

아이템67 : 최적화는 신중히 하라

 최적화 격언 세 가지

1.
그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다.
2.
자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다.
3.
최적화 할 때는 다음 두 규칙을 따르라.
a.
하지 마라.
b.
아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라.

 좋은 프로그램을 작성하라

성능 떄문에 견고한 구조를 희생시키지 마라.
빠른 프로그램보다는 좋은 프로그램을 작성해야 한다.
좋은 프로그램이란
정보 은닉 원칙을 따르므로, 개별 구성요소의 내부를 독립적으로 설계할 수 있다.
시스템 나머지에 영향을 주지 않고 각 요소를 다시 설계할 수 있다.
완성된 설계의 기본 틀을 변경 → 유지보수하거나 개선하기 어려운 구조의 시스템이 만들어지기 쉽다.

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

변경하기가 가장 어려운 설계 요소는 컴포넌트끼리 혹은 외부 시스템과의 소통 방식이다.
이런 설계 요소들은 변경하기 어렵거나 불가능할 수 있으며 동시에 시스템 성능을 심각하게 제한할 수 있다.

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

public 타입을 가변으로 만들면?
불필요한 방어적 복사를 수없이 유발할 수 있다.
상속으로 설계한 클래스는?
컴포지션으로 해결할 수 있음에도 이렇게 설계 했다면 상위 클래스에 영원히 종속되고
성능 제약까지 물려받게 된다.
인터페이스 대신 구현 타입을 사용한다면?
특정 구현체에 종속되게 하여 나중에 더 빠른 구현체가 나오더라도 이용하지 못하게 된다.

 잘 설계된 API가 보통 성능도 좋다

성능을 위해 API를 왜곡하지 말아야 한다.
성능 문제는 플랫폼이나 소프트웨어의 다음 버전에서 사라질 수 있다.
왜곡된 API와 이를 지원하는 데 따르는 고통이 지속될 수 있다.
신중하게 설계하여 깨끗하고 명확한 구조를 갖췄다면, 최적화를 고려해보자.

 성능 측정

최대한 최적화를 하지 말고, 만약 해야 한다면 각각의 최적화 시도 전후로 성능을 측정해야 한다.
눈에 띄게 성능을 높이지 못하고 심지어 더 나빠지게 할 수 있다.
주요 원인은 시간을 잡아먹는 부분을 추측하기가 어렵다는 것이다.
프로파일링 도구
최적화 노력을 어디에 집중해야 할지 찾는 데 도움을 준다.
개별 메서드 소비 시간, 호출 횟수 같은 런타임 정보를 제공한다.
시스템 규모가 커질수록 프로파일러가 더 중요해진다.

 핵심 정리

빠른 프로그램을 작성하려 안달하지 말자.
빠른 프로그램보다 좋은 프로그램을 작성하자.
시스템 구현을 완료했다면 성능을 측정해보자.
충분히 빠르면 그것으로 마무리하라.
최적화를 한다면 프로파일러를 사용하여 원인부터 명확하게 밝혀내자.
모든 변경 후에는 성능을 측정하자.