728x90

807p~

839p~

 

참석자 : 김승제, 이용준

기간 : 21-08-10~21-08-12

리뷰 : 21-08-12

 

Chapter 25  코드 최적화 전략

814p. 코드 최적화는 일반적으로 아키텍처, 알고리즘 선택과 같이 극적인 향상을 제공하지도 않고, 성능을 향상시키기 가장 쉬운 방법도 아니다.  하지만 진정한 프로그래머가 되는 통과 의례이다. 여러분과 다른 프로그래머들을 제외한 어느 누구도 일반적으로 여러분의 코드가 얼마나 엄격한지에 대해서 신경 쓰지 않는다. 그럼에도 불구하고 프로그래밍 문화에서는 아주 미세하게 효율적인 코드를 작성하는 것은 여러분이 훌륭한 프로그래머라는 것을 증명한다.

 

818p. 코드를 작성하면서 최적화해야 한다! - 거짓! : 세부적인 최적화를 하느라 너무 바빠서 중요한 전역적인 최적화를 뭇히나는 경우가 생긴다.

 

820p. 최적화 시기 : 고급 설계를 사용하라. 프로그램을 올바로 만들어라. 나중에 작업하기 쉽도록 모듈화하고 변경이 쉽도록 만들어라. 정확하게 완성되었을 때, 성능 검사하라. 만약 프로그램을 못 쓰게 하고 싶다면, 빠르고 작게 만들어라. 최적화가 필요하다는 것을 알게 될 때까지 최적화를 하지 않는다.

 

823p. 비효율성의 공통적인 원인 : 입/출력 연산, 메모리 페이징(page), 시스템호출(컨텍스트 스위칭 발생), 인터프리트 언어, 오류

 

831p. 만약 보다 효율적인지를 알기 위해서 측정할 가치가 없다면, 성능 도박을 위해서 명료함을 제물로 바칠만한 가치도 없다.

 

827p. 공통적인 연산의 상대적인 성능 비용 

 

Chapter26 코드 최적화 

 

논리구조

답을 알고 있을 때에는 테스트를 중단하라

- break문 사용

 

빈도에 따른 테스트 정렬

- 거의 항상 참인경우가 가장 먼저 수행되도록 정렬한다.

 

유사한 논리 구조의 성능을 비교해라

- case문과 switch문의 경우 언어보다 성능의 우위가 다르다. 간단히 말해서 결과를 측정할만한 신뢰할 수 있는 방법이 없다.

 

복잡한 표현식을 테이블 참조로 대체하라

- 테이블 참조가 복잡한 논리 구조를 따지는 것보다 더 빠른 경우가 있다.

 

소극적인 평가를 사용하라

 

루프

언스위칭

- 루프 검사를 밖에서 하는 것을 고려해라

 

재밍

- 결합가능한 루프를 하나로 묶어라

 

언롤링

- 루프의 보조 수단 코드의 양을 줄이는 것이다. 하지만 전체 코드량이 늘어나고 가독성이 떨어지는 단점이있다. 또한 코드 최적화에 대한 보증이 없다. 언어나 컴파일러에 따라 상이하기 떄문이다.

 

루프 내부 작업의 최소화

 

감시값

- 루프의 지속 중단 여부를 결정 짓는 감시값을 외부에서 정의해서 사용해라

 

가장 빈번한 루프를 안쪽에 작성해라

 

강도감소

- 곱셉과 같이 시간이 많이 걸리는 연산을 덧셈과 같이 시간이 적게 걸리는 연산으로 대체해라

 

데이터변환

부동소수점 대신 정수를 사용하라

 

가능한 적은 차수 배열을 사용하라

 

배열에 대한 참조를 최소화해라

 

보조 인덱스를 사용하라

- 독립적인 병렬 인덱스를 고려해라.

 

캐싱을 사용하라

 

표현식

대수 항등식을 사용하라

- 불필요한 연산이 들어가지 않도록 해라

 

강도 감소를 사용하라

- 강도 감소 비용이 많이 드는 연산을 피해라

 

컴파일 시간에 초기화하라

 

시스템 루핀을 주의하라

 

상수의 정확한 형을 사용하라

 

결과를 사전에 계산하라

 

공통적인 하위 표현식을 제거하라

 

루틴

루틴을 인라인으로 재작성하라

 

저급언어를 이용한 재구성

 

728x90

+ Recent posts