- 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 많다.
- 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다.
- 최적화를 할 때는 다음 두 규칙을 따르라.
- 하지 마라.
- 아직 하지 마라. (명백한 해법을 찾을 때까지)
- 좋은 프로그램은 정보 은닉 원칙을 따른다.
- 따라서 나머지에 영향을 주지 않고도 쉽게 재설계할 수 있다.
- (당연히) 아니다.
- 성능이 떨어지는 아키텍처를 처음부터 사용하면, 최적화를 위해 시스템 전체를 다시 작성해야 할 수도 있다.
- 설계 단계에서 성능을 반드시 염두에 두어야 한다.
- 다른 컴포넌트 or 외부 시스템과의 소통 관련 부분은 변경이 어렵다.
- API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등
- 시스템 성능을 심각하게 제한할 수 있음
- 예시 1. public 타입을 가변으로 만들면 불필요한 방어적 복사 로직을 작성해야 한다.
- 예시 2. 컴포지션으로 해결할 수 있음에도 상속을 쓰면 상위 클래스에 영원히 종속된다.
- 예시 3. 인터페이스가 있는데 굳이 구현 타입을 쓰면 나중에 더 빠른 구현체가 나오더라도 사용할 수 없게 된다.
- 성능을 위해 API를 왜곡하지 말자. 성능 문제는 다음 버전에서 사라질 수도 있지만, 왜곡된 API와 이를 지원하는 데 따르는 고통은 영원히 계속될 것이다.
- 일단 깔끔한 구조를 갖춘 프로그램을 완성한 다음 최적화를 고려해 보자.
- 각각의 최적화 시도 전후로 성능을 측정하자.
- 생각보다 성능 개선이 안 될 때가 많을 것이다. → 시간 낭비
- 자바는 성능 모델이 정교하지 않아서 이러한 작업은 특히 더 중요하다.
- 프로파일링 도구: 최적화 노력을 어디에 집중해야 할지 찾아줌
- O(n^2) 혹은 그 이상의 비효율적인 알고리즘
- 시스템 규모가 커지면 프로파일러가 더 중요
- JMH(Java Microbenchmark Harness): 성능 측정 도구
- 프로파일러는 아니지만 벤치마킹을 통해 성능을 잘 보여준다.
- 빠른 프로그램보다 일단은 좋은 프로그램 작성하셈.
- 근데 외부 의존성 있는 친구는 성능 생각해야 됨.
- 일단 충분히 빠르면 걍 냅두셈.
- 근데 너무 느려서 최적화할 거면 프로파일러 + 성능 측정 도구 써서 꼭 성능 측정하셈.