ITEM 67: 최적화는 신중히 해라
Last updated
Was this helpful?
Last updated
Was this helpful?
그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다. - 윌리엄 울프
자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. - 도널드 크누스
최적화를 할 떄는 다음 두 규칙을 따르라. 첫 번째. 하지 마라. 두 번째, (전문가 한정) 아직 하지마라. 다시 말해, 완전히 명백하고 최적화 되지 않은 해법을 찾을 때까지는 하지 마라. - M. A. 잭슨
최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽다.
빠른 프로그램 보다는 좋은 프로그램(견고한 구조)을 작성하는 것이 더 중요하다. 좋은 프로그램은 정보 은닉 원칙을 따라 개별 구성요소를 독립적으로 설계할 수 있고, 다른 요소에 영향을 주지 않고도 다시 설계할 수 있다. 아키텍처의 결함이 성능을 제한하는 상황이면, 시스템 전체를 다시 구현해야 할 수도 있다. 반드시, 설계 단계에서 성능을 고려해야 한다.
내부 데이터를 변경할 수 있게 만들면 불필요한 방어적 복사를 수없이 유발할 수 있다.
컴포지션으로 해결할 수 있음에도 상속 방식으로 설계한 클래스는 상위 클래스에 종속되며, 성능 제약까지도 물려받는다.
인터페이스도 있는데 굳이 구현 타입을 사용하는 것은 좋지 않다.
최적화 시도가 성능을 눈에 띄게 높이지 못하는 경우가 많으며, 심지어 더 나빠지는 경우도 있다. 일반적으로 90%의 시간을 10%의 코드에서 사용하는 경우가 많으며, 프로그램에서 그 부분을 찾아내는 것이 쉽지 않다.
프로파일링 도구는 개별 메서드의 소비 시간과 호출 횟수와 같은 런타임 정보를 제공해, 어느 부분이 최적화가 필요한지 파악하는데 좋다.
는 프로파일러는 아니지만 자바 코드의 상세한 성능을 알기 쉽게 보여주는 마이크로 벤체 마킹 프레임 워크다. 자바는 작성된 코드와 CPU에서 수행하는 명령 사이의 격차가 커서 최적화로 인한 성능 변화를 예측하기가 어려우므로 반드시 전후로 성능 테스트가 필요하다.