최적화를 할 때는 다음의 규칙을 따르라.
1. 하지마라
2. (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법은 찾을 때까지는 하지마라.최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇다.
성능 때문에 견고한 구조르 희생하지 말자. 빠른 프로그램보다는 좋은 프로그램을 작성하라
설계 단계에서 성능을 염두에 두어야 한다.
1. 성능을 제한하는 설계를 피하라
완성 후 변경하기가 가장 어려운 설계 요소는 바로 컴포넌트끼리, 혹은 외부 시스템과의 소통 방식이다,
ex) API, 영구 저장용 데이터 포맷
이런 설계 요소들은 완성 후에는 변경하기 어렵거나 불가능할 수 있으며, 동시에 시스템 성능을 심각하게 제한할 수 있다.
2. API를 설계할 때 성능에 주는 영향을 고려하라
- public 타입을 가변으로 만들면(내부 데이터를 변경할 수 있게 만들면) 불필요한 방어적 복사를 수없이 유발할 수 있다.
ex) java.awt.Component 클래스의 getSize 메서더의 경우 가변 Dimension 인스턴스를 반환한다. 따라서 getSize를 호출하는 모든 곳에서 Dimension 인승턴스를 방어적으로 복사하느라 새로 생성해야 한다.
1) 이를 불변을 반환하도록 설계하는 게 이상적
2) getSize를 getWidth, getHeight로 나누는 방법도 있다.(즉 기본 타입 값들을 따로따로 반환하는 방식) - 컴포지션으로 해결할 수 있음에도 상속으로 설계한 public 클래스는 상위 클래스에 영원히 종속되며 그 성능 제약까지도 물려받게 된다.
- 인터페이스가 있음에도 굳이 구현 타입을 사용하는 것 역시 좋지 않다.
특정 구현체에 종속되게 하여, 나중에 더 빠른 구현체가 나오더라도 이용하지 못 하게 된다.
3. 성능을 위해 API를 왜곡하는 건 좋지 않다.
API를 왜곡하도록 만들면 클라이언트 코드는 기존의 API를 영원히 호출하여 고통이 지속된다.
신중하게 설계하여 멋진 구조를 갖춘 프로그램을 완성한 다음에야 최적화를 고려할 수 있다.
각각의 최적화 시도 전후로 성능을 측정하라
프로파일링 도구는 최적화 노력을 어디에 집중해야 할지 찾는데 도움을 준다.
개별 메서드의 소비 시간과 호출 횟수 같은 런타임 정보를 제공하여, 집중할 곳은 물론 알고르짐을 변경해야 한다는 사실을 알려준다.
또한, jmh도 자바 코드의 상세한 성능을 알기 쉽게 보여주는 마이크로 벤치마킹 프레임워크다.
ex) JProfiler, YourKit, Java VisualVM, the Netbeans Profiler
Java VisualVM( 버전 7 이상의 JDK에 내장되어 있음) 및 JMX(Java Management eXtensions) 사용법
https://bcho.tistory.com/789
http://asuraiv.blogspot.com/2015/09/performance-visualvm-jmx-tomcat-cpu.html https://geekflare.com/enable-jmx-tomcat-to-monitor-administer/
좋은 프로그램을 작성하면 성능은 따라온다.
다만, 시스템을 설계할 때 API, 네트워크 프로토콜, 영구 저장용 데이터 포맷을 설계할 때는 성능을 염두에 두자.
이후 시스템 구현을 완료하면 성능을 측정하자.
이때 프로파일링 도구를 활용해 문제가 되는 지점을 찾아 최적화를 진행하자.
만약, 알고리즘의 문제라면 알고리즘만 변경해도 최적화가 된다.
