(맹목적인 어리석음을 포함해) 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다. (심지어 효율을 높이지도 못하면서) - 윌리엄 울프
(전체의 97% 정도인) 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. - 도널드 크누스
최적화를 할 때는 다음의 두 규칙을 따르라. 첫 번째 하지 마라. 두 번째 (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라.
위 격언들이 시사하는 바는 섣부른 최적화는 빠르지도 않고 제대로 동작하지도 않으면서 수정하기 어려운 소프트웨어를 탄생시킨다는 것이다.
그렇다고 성능 문제를 완전히 무시하라는 얘기는 아니다.
잘 설계된 API는 성능도 좋은 게 보통이다. 성능을 위해 API를 왜곡하는 건 매우 안 좋은 생각이다.
시도한 최적화 기법이 성능을 높이지 못하는 경우가 많고 심지어 나빠지게 할 때도 있다. 주 원인은 성능 병목이 어디서 발생하는지 파악하기 어렵다는 데 있다.
최적화 성능 측정은 성능 모델이 덜 정교한 자바에서 중요성이 더 크다. 자바는 개발자가 작성하는 코드와 CPU에서 수행하는 명령 사이의 추상화 격차가 크기 때문에 구현 시스템, 릴리스마다 차이가 있다. 때문에 최적화의 효과를 각각의 환경에서 측정해야 한다.
좋은 프로그램을 작성하다 보면 성능은 따라오게 마련이다. 하지만 시스템 설계 시(API, 네트워크 프로토콜, 영구 저장용 데이터 포맷)에는 성능을 염두해야 한다. 최적화를 한다면 성능을 측정해 봐야 한다. 충분히 빠르면 그것으로 끝이다.