•
과거 컴퓨터 자원이 제한적일 때는 효율화가 최고의 관심사였다. 성능이 향상되면서 효율을 위한 노력들이 얼마나 유지보수를 어렵게 하는지 깨닫게 되어 사장되었으나 임베디드 분야에선 종종 사용된다.
•
성능은 전략과 전술이라는 두 측면에서 설명할 수 있는데, 여기선 전략을 다룬다.
•
성능이 무엇이고 왜 중요한지, 성능 개선 목표를 달성하기 위해 일반적으로 어떻게 접근하는지를 다룬다.
1. 성능이란?
품질의 특성과 성능
•
코드의 속도를 개선하려고 쓰는 시간만큼 다른 품질 특성에는 시간을 덜 들이게 되므로 속도를 빠르게 만들려고 다른 특성을 희생하는 것을 주의해야 한다.
성능과 코드 튜닝
•
효율화를 최우선 순위로 결정했다면 코드 수준에서 속도나 크기 중 어느 것을 향상시킬지 선택하기에 앞서 몇 가지 사항을 고려해야 한다.
•
각 관점에서 바라본 효율화가 무엇일지 고민해야한다.
◦
프로그램 요구사항
▪
성능 문제를 해결하기 전, 성능 요구사항이 적절한지 알아보자.
◦
프로그램 설계
◦
클래스와 메소드 설계
◦
운영체제 상호작용
◦
코드 컴파일
◦
하드웨어
◦
코드 튜닝
2. 코드 튜닝 소개
•
코드 튜닝의 문제점은 효율적인 코드가 항상 더 낫다라곤 할 수 없다는 점이다.
파레토 법칙
•
20%의 노력으로 80%의 결과를 얻을 수 있다고 설명하는 법칙이다.
•
전체적인 시스템 개선보다 비즈니스 로직이 집중된 부분을 수정하여 효율적인 결과를 이끌어낼 수 있는지 인지하자.
노부인들의 이야기
•
고급 언어에서 코드를 줄이면 결과적으로 기계어의 속도나 크기를 향상시키지 않는다.
◦
짧을수록 빠르다는 것은 언제나 참이 아니다.
•
빠른 프로그램은 정확한 프로그램만큼 중요하지 않다.
◦
속도나 크기가 중요한 관심사지만 이는 생각보다 중요하지 않다. 이들을 고려하다 다른 품질을 저하시키지 않도록 하자.
3. 느리고 비대한 부분
비효율성의 공통적인 원인
•
입출력 연산
•
시스템 호출
◦
시스템 루틴에 대한 호출은 종종 비싼데, 컨텍스트 스위칭이 발생하기 때문이다.
•
인터프리터 언어
◦
각 프로그래밍 언어 명령을 실행 전에 처리해야 하므로 상당한 성능 손해를 보는 경향이 있다.
•
오류
4. 측정
•
경험은 최적화에 큰 도움을 주지 못한다. 객관적인 수치만이 지표로써 적합하다.
측정은 정확해야 한다
•
측정을 위해 다른 사람의 도구를 사용하든 자신만의 코드를 작성하든 상관없이 실행 시간을 정확하게 측정할 수 있는 방법을 택하라.
5. 반복
•
하나의 기법만을 적용하려 하지 말고 결합이 가능하니 효과가 있는 기법을 발견했다 하더라도 꾸준히 다른 방법을 시도해보라.
6. 코드 튜닝 단계 요약
1.
이해하고 변경하기 쉬운 잘 설계된 코드를 사용하여 소프트웨어를 개발한다.
2.
성능이 좋지 않다면
a.
백업을 미리 저장해놓는다.
b.
과열지점을 찾아서 시스템을 측정한다.
c.
성능이 취약한 것이 부적절한 설계 때문인지, 데이터형이나 알고리즘 때문인지 판단하고 코드 튜닝이 적절한지 판단한다. 적절하지 않다면 1단계로 돌아간다.
d.
규명된 병목을 튜닝한다.
e.
한 번에 하나씩 성능을 측정한다.
f.
코드의 성능이 향상되지 않았다면 백업해놓은 코드로 되돌아간다.
3.
2단계를 반복한다.
요점 정리
•
성능은 품질의 한 측면일 뿐이며 일반적인 경우에 가장 중요한 항목도 아니다. 정밀하게 튜닝된 코드는 전체적인 성능의 한 측면일 뿐이며 그 효과가 눈에 잘 보이지도 않는다.
◦
프로그램 아키텍처, 상세 설계, 자료구조와 알고리즘 선택이 일반적으로 콛의 효율성보다 프로그램의 수행 속도와 크기에 더 큰 영향을 미친다.
•
양적인 측정은 성능 최대화의 핵심이다. 그것은 성능 향상이 정말 중요한 영역을 찾는데 필요하고 최적화가 성능을 향상시켰는지를 검증하는 데도 필요하다.
•
대부분의 프로그램은 작은 코드 영역에서 대부분의 시간을 보낸다. 코드를 측정하기 전까지는 그것이 어느 코드인지 알 수 없다.
•
코드 튜닝을 통해 원하는 만큼의 성능을 개선하기 위해선 일반적으로 여러번 반복해야 한다.
•
초기 코드 작성 시 성능 작업을 대비하는 가장 좋은 방법은 이해하고 수정이 쉬운 분명한 코드를 작성해두는 것이다.
