최적화 격언 세 가지
1.
그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다.
2.
자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다.
3.
최적화 할 때는 다음 두 규칙을 따르라.
a.
하지 마라.
b.
아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라.
좋은 프로그램을 작성하라
•
성능 떄문에 견고한 구조를 희생시키지 마라.
•
빠른 프로그램보다는 좋은 프로그램을 작성해야 한다.
•
좋은 프로그램이란
◦
정보 은닉 원칙을 따르므로, 개별 구성요소의 내부를 독립적으로 설계할 수 있다.
◦
시스템 나머지에 영향을 주지 않고 각 요소를 다시 설계할 수 있다.
•
완성된 설계의 기본 틀을 변경 → 유지보수하거나 개선하기 어려운 구조의 시스템이 만들어지기 쉽다.
성능을 제한하는 설계를 피하라
•
변경하기가 가장 어려운 설계 요소는 컴포넌트끼리 혹은 외부 시스템과의 소통 방식이다.
•
이런 설계 요소들은 변경하기 어렵거나 불가능할 수 있으며 동시에 시스템 성능을 심각하게 제한할 수 있다.
API 설계할 때 성능에 주는 영향을 고려하라.
•
public 타입을 가변으로 만들면?
◦
불필요한 방어적 복사를 수없이 유발할 수 있다.
•
상속으로 설계한 클래스는?
◦
컴포지션으로 해결할 수 있음에도 이렇게 설계 했다면 상위 클래스에 영원히 종속되고
성능 제약까지 물려받게 된다.
•
인터페이스 대신 구현 타입을 사용한다면?
◦
특정 구현체에 종속되게 하여 나중에 더 빠른 구현체가 나오더라도 이용하지 못하게 된다.
잘 설계된 API가 보통 성능도 좋다
•
성능을 위해 API를 왜곡하지 말아야 한다.
•
성능 문제는 플랫폼이나 소프트웨어의 다음 버전에서 사라질 수 있다.
•
왜곡된 API와 이를 지원하는 데 따르는 고통이 지속될 수 있다.
•
신중하게 설계하여 깨끗하고 명확한 구조를 갖췄다면, 최적화를 고려해보자.
성능 측정
•
최대한 최적화를 하지 말고, 만약 해야 한다면 각각의 최적화 시도 전후로 성능을 측정해야 한다.
•
눈에 띄게 성능을 높이지 못하고 심지어 더 나빠지게 할 수 있다.
◦
주요 원인은 시간을 잡아먹는 부분을 추측하기가 어렵다는 것이다.
•
프로파일링 도구
◦
최적화 노력을 어디에 집중해야 할지 찾는 데 도움을 준다.
◦
개별 메서드 소비 시간, 호출 횟수 같은 런타임 정보를 제공한다.
◦
시스템 규모가 커질수록 프로파일러가 더 중요해진다.
핵심 정리
•
빠른 프로그램을 작성하려 안달하지 말자.
◦
빠른 프로그램보다 좋은 프로그램을 작성하자.
•
시스템 구현을 완료했다면 성능을 측정해보자.
◦
충분히 빠르면 그것으로 마무리하라.
•
최적화를 한다면 프로파일러를 사용하여 원인부터 명확하게 밝혀내자.
◦
모든 변경 후에는 성능을 측정하자.
