요약
•
최적화를 할 때는 여러 상황들을 신중하게 고려하여 진행하자.
최적화와 관련된 격언
그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다.(심지어 효율을 높이지도 못한다)
윌리엄 울프
전체의 97% 정도인 자그마한 효율성은 잊자. 섣부른 최적화가 만악의 근원이다.
도널드 크누스
최적화를 할 때는 두 규칙을 따르라.
첫 번째, 하지 마라.
두 번째, (전문가 한정) 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라.
M. A. 잭슨
•
이 격언들은 자바 탄생 20년 전에 나온 말들로, 최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽다.
•
섣부른 최적화는 빠르지도 않고 제대로 동작하지도 않으면서 수정하기는 어려운 소프트웨어를 만들 수 있다.
적절한 최적화
•
빠른 프로그램보다 좋은 프로그램을 작성하자.
◦
성능 때문에 견고한 구조를 희생하지 말고, 좋은 프로그램이지만 성능이 나오지 않는다면 아키텍처 자체가 최적화 할 수 있는 길을 안내해 줄 것이다.
◦
좋은 프로그램은 정보 은닉 원칙을 따라 개별 구성요소를 독립적으로 설계 할 수 있어, 시스템의 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다.
◦
다만 아키텍처의 결함이 성능을 제한하는 상황이 오지 않게, 설계 단계에서 반드시 성능을 염두에 두어야 한다.
•
성능을 제한하는 설계를 피하라
◦
API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등 외부 시스템과 소통하는 방식이나 컴포넌트끼리 소통하는 방식은 완성 후 변경하기가 가장 어려운 설계 요소이다.
◦
이런 설계 요소들로 인해 완성 후에 변경이 어렵거나 불가능하고, 시스템 성능이 심각하게 제한될 수 있다.
•
API를 설계할 때는 성능에 주는 영향을 고려하라
◦
클래스나 메서드를 public 타입으로 공개하면, 내부 데이터를 수정할 수 없도록 방어적 복사를 수없이 많이 해야하는 상황은 주의하자.
◦
상속으로 상위 클래스의 성능 제약까지 물려받는 public 클래스를 만들지 말고 컴포지션으로 해결하자.
◦
참조를 구현 타입으로 받지말고 인터페이스로 받아, 특정 구현체에 종속되게 만들지 말고 나중에 더 빠른 구현체가 나오면 쉽게 바꿀 수 있게 하자.
•
성능을 위해 API를 왜곡하지 말자
◦
잘 설계된 API는 일반적으로 성능도 좋다.
◦
신중하게 설계하여 깨끗하고 명확한 구조를 갖추고, 최적화를 고려하자.
•
최적화 시도 전후로 성능을 측정하라
◦
프로그램에서 시간을 잡아먹는 부분을 추측하기 어렵기 때문에, 최적화 시도가 성능을 눈에 띄게 높이지 못하거나 더 나빠지게 하는 경우도 있다.
◦
자바에서는 작성된 코드와 CPU에서 수행하는 명령 간의 추상화 격차가 커서, 최적화로 인한 성능 변화를 일정하게 예측하기가 어렵다.