[Effective Java] 잘 판단해서 최적화하자

[Effective Java] 잘 판단해서 최적화하자

-
최적화에 대한 명언이 있다.

더 많은 컴퓨팅 죄악이 다른 어떤 한 가지 이유(무지로 인한 어리석음을 포함해서)보다는 효율성(달성이 안 되는)의 이름으로 저질러진다.

사소한 효율성은 잊어야 한다. 97%의 시간에 대해 논하자. 성급한 최적화는 모든 죄악의 근원이다.

최적화에 관한 두 가지 규칙을 따르자.
    규칙 1. 하지 말자.
    규칙 2. (전문가에 한해서). 아직 하지 말자. 정말 최적화되지 않은 솔루션이 있을 때까지는.


-
성급한 최적화는 얻는 것보다 잃는 것이 더 많기 쉽다.
최적화를 하면서 빠르지도 않고 제대로 동작하지도 않으며, 문제를 쉽게 해결하기도 어려운 소프트웨어를 만들기도 쉽다.


-
성능 때문에 훌륭한 아키텍쳐 원리를 포기하지 말자.
빠른 것보다는 좋은 프로그램 작성에 노력하자.
만일 잘된 프로그램이 충분히 빠르지 않다면, 아키텍쳐를 최적화해야 할 것이다.
좋은 프로그램은 정보 은닉을 실현한다.


-
그렇다고 프로그램이 완성될 때까지 성능 관점을 무시해도 좋다는 것은 아니다.
구현상의 문제점은 향후의 최적화에서 바로잡을 수 있다.
그러나 성능을 제한하는 아키텍쳐 결함은 시스템을 재 작성해야 바로 잡을 수 있다.
문제가 생긴 후 기본 설계를 변경한다면, 유지보수와 진화가 어려운 부실한 구조의 시스템을 초래할 수 있다.
그러므로 설계 단계에서 성능을 고려해야 한다.
즉, 성능을 제한하는 설계상의 결정을 하지 않도록 노력하자.


-
API의 설계 결정이 성능에 미치는 영향을 고려하자.
public 타입을 가변으로 만들면 불필요한 방어복사를 많이 초래할 수 있다.
마찬가지로 컴포지션이 적합했었을 public 클래스에 상속을 사용하면, 그 클래스가 영원히 자신의 수퍼 클래스에 묶이게 된다.
( 수퍼 클래스는 서브 클래스의 성능을 인위적으로 제한할 수 있다. )
API 에서 인터페이스보다 구현체 타입을 사용하면 특정 구현체에 얽매이게 된다.
향후에 실행 속도가 더 빠른 구현체를 작성하더라도 기존 API 를 변경하기 어렵다.


-
최적화를 고려할 시기는, 신중하게 프로그램을 설계한 후 명확하고, 강경하고, 잘 구축된 코드를 만든 후이다.


-
최적화를 할 때마다 시작 전과 끝난 후의 성능을 측정하다.
최적화가 성능 개선에 그다지 큰 효과가 없는 경우가 종종 있고, 때로는 더 나쁘게 만들기도 한다.


-
프로파일링 도구를 사용하면 최적화의 초점을 어디에 둘 것인지 결정하는데 도움이 될 수 있다.


-
최적화의 효과를 측정할 필요성은 종래의 플랫폼보다 자바 플랫폼이 더욱 크다.
자바 프로그래밍 언어가 강력한 성능 모델을 갖고 있지 않기 때문이다.
다시 말해 다양한 기본 연산 수행시 들어가는 상대적 비용이 잘 정의되어있지 않다.
프로그래머가 작성하는 코드와 CPU가 실행하는 것 간의 의미적 차이가 종래의 컴파일 언어에 비해 훨씬 더 크다.


-
자바는 성능 모델이 잘못 정의된 점도 있지만, JVM마다, 배포판마다, 프로세서마다 성능이 제 각각이라는 단점도 수반한다.
따라서 여러 종류의 JVM, 여러종류의 하드웨어 등의 조건에서 측정해봐야 한다.

Summary

실행 속도가 빠른 프로그램 작성에 너무 매달리지 말고 양질의 프로그램 작성에 전력하자.
그러면 속도는 자연히 따라올 것이다.
시스템을 설계할 때 특히 API, 통신 프로토콜, 영구적인 보존이 필요한 데이터 형식(DB 등)을 설계할 때 성능 문제를 심사숙고하자.
시스템 구축이 끝났을 때 성능을 측정하자.
만일 충분히 빠르다면 다된 것이고, 그게 아니라면 프로파일러 도구의 도움을 받아 문제의 근원을 찾자.
그 다음에 시스템 중 그것과 관련된 부분의 최적화를 실시하자.
첫 번째 단계는 알고리즘을 잘 선택했는지 검사하는 것이다.
알고리즘을 잘못 선택하면 아무리 최적화해도 소용없기 때문이다.
변경이 생길 때마다 성능을 측정하면서 만족할 때까지 이 절차를 반복하자.

API, CPU, DB, Effective JAVA, jvm, Public, [Effective Java] 잘 판단해서 최적화하자, 가변, 고려할 시기, 구현상, 구현체 타입, 끝난 후, 노력, 단점, 데이터 형식, 동작, 명언, 명확, 무지, 반복, 방어 복사, 배포판, 사소한 효율성, 상대적 비용, 상속, 서브 클래스, 설계 결정, 설계 단계, 설계상 결정, 성급한 최적화, 성능, 성능 고려, 성능 모델, 성능 제한, 성능 측정, 속도, 시스템, 시스템 구축, 시작 전, 아키텍쳐, 알고리즘, 양질의 코드, 어려운 소프트웨어, 어리석음, 영구적 보존, 완성, 원리, 의미적 차이, 인터페이스, 자바, 자바 플랫폼, 잘 판단, 정보 은닉, 제각각, 제한, 조건, 종래, 죄악의 근원, 최적화, 최적화 규칙, 최적화 초점, 충분히 빠르다, 측정, 컴파일 언어, 컴포지션, 컴퓨팅, 통신 프로토콜, 프로그램 작성, 프로세서, 프로파일러, 프로파일링 도구, 하드웨어, 하지 말자, 효율성