[ Item 67 ] 최적화는 신중히 하라

[ybell1028]

최적화 격언 세 개

(맹목적인 어리석음을 포함해) 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다(심지어 효율을 높이지도 못하면서). - 윌리엄 울프

(전체의 97% 정도인) 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. - 도널드 크누스

최적화를 할 때는 다음 두 규칙을 따르라.
첫 번째, 하지 마라.
두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지마라. - M. A. 잭슨

• 성능 때문에 견고한 구조를 희생하지 말자.
• 빠른 프로그램 보다는 좋은 프로그램을 작성하라.
• 좋은 프로그램이지만 원하는 성능이 나오지 않는다면 그 아키텍처 자체가 최적화할 수 있는 길을 안내해줄 것이다.
• 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있다.
• 따라서 시스템의 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다. (아이템 15)

상세 설명

프로그램을 완성할 때 까지의 성능 문제를 무시하라는 뜻이 아니다.
구현상의 문제는 나중에 최적화해 해결할 수 있지만, 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고는 해결하기 불가능할 수 있다.
완성된 설계의 기본 틀을 변경하려다 보면 유지보수하거나 개선하기 어려운 꼬인 구조의 시스템이 만들어지기 쉽기 떄문이다.
따라서 설계 단계에서 성능을 반드시 염두에 두어야 한다.

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

• 컴포넌트끼리, 혹은 외부 시스템과의 소통 방식 및 API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등이 대표적
• 이런 설계 요소들은 완성 후에는 변경하기 어렵거나 불가능할 수 있으며, 동시에 시스템 성능을 심각하게 제한할 수 있다.

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

• public 타입을 가변으로 만들면(내부 데이터를 변경할 수 있게 만들면) 불필요한 방어적 복사를 수없이 유발할 수 있다. (아이템 50)
• 컴포지션(구성)으로 해결할 수 있음에도 상속 방식으로 설계한 public 클래스는 상위 클래스에 영원이 종속되며 그 성능 제약까지도 물려받게 된다.
• 인터페이스도 있는데 굳이 구현 타입을 사용하는 것 역시 좋지않다. 특정 구현체에 종속되게 하여, 나중에 더 빠른 구현체가 나오더라도 이용하지 못하게 된다. (아이템 64)

성능을 위해 API를 왜곡하지 말라

• 성능 문제는 해당 플랫폼이나 아랫단 소프트웨어의 다음 버전에서 사라질 수도 있지만, 왜곡된 API와 이를 지원하는 데 따르는 고통은 계속될 것이다.
• 신중하게 설계하여 깨끗하고 명확하고 멋진 구조를 갖춘 프로그램을 완성한 다음에야 최적화를 고려해볼 차례가 된다.
  • 물론 성능에 만족하지 못할 경우에 한정된다.

성능 측정

잭슨이 소개한 최적화 규칙 두가지 외에 하나를 더 추가한다면 "각각의 최적화 시도 전후로 성능을 측정하라" 정도가 될 수 있다.

아마도 측정 결과에 놀랄 때가 많은 것이다. 시도한 최적화 기법이 성능을 눈에 띄게 높이지 못하는 경우가 많고, 심지어는 더 나빠지게 할 때도 있다.

프로파일링 도구(profiling tool)는 최적화 노력을 어디에 집중해야 할지 찾는 데 도움을 준다.
이런 도구는 개별 메서드의 소비 시간과 호출 횟수 같은 런타임 정보를 제공하여, 집중할 곳은 물론 알고리즘을 변경해야 한다는 사실을 알려주기도 한다.

그 외에 jmh도 언급해둘 만한 도구다. 프로파일러는 아니지만 자바 코드의 상세한 성능을 알기 쉽게 보여주는 마이크로 벤치마킹 프레임 워크다.

최적화 시도 전후의 성능 측정은 성능 모델이 덜 정교한 자바에서는 중요성이 더욱 크다.
자바는 다양한 기본 연산에 드는 상대적인 비용을 덜 명확하게 정의하고 있다. 다시 말해, 프로그래머가 작성하는 코드와 CPU에서 수행하는 명령 사이의 '추상화 격차'가 커서 최적화로 인한 성능 변화를 일정하게 예측하기가 그만큼 더 어렵다.

자바의 성능 모델은 정교하지 않을뿐 더러 구현 시스템, 릴리스, 프로세서마다 차이가 있다.
여러분의 프로그램을 여러 가지 자바 플랫폼이나 여러 하드웨어 플랫폼에서 구동한다면 최적화의 효과를 그 각각에서 측정해야 한다.

핵심 정리

• 빠른 프로그램을 작성하려 안달하지 말자. 좋은 프로그램을 작성하다 보면 성능은 따라오게 마련이다.
• 하지만 시스템을 설계할 때, 특히 API, 네트워크 프로토콜, 영구 저장용 데이터 포맷을 설계할 떄는 성능을 염두에 두어야 한다.
• 시스템 구현을 완료했다면 이제 성능을 측정해보라. 충분히 빠르면 그것으로 끝이다.
  • 그렇지 않다면 프로파일러를 사용해 문제의 원인이 되는 지점을 찾아 최적화를 수행하라.
  • 가장 먼저 알고리즘을 확인하자. 알고리즘을 잘못 골랐다면 다른 저수준 최적화는 아무리 해봐야 소용이 없다.