- 언젠가 성능 문제가 수면 위로 오르면 문제를 쉽게 해결하기 위해 최대한 인터페이스의 성능을 최적화
- 요구 사항은 계속 변함
- API를 릴리즈한 이후로 언젠가는 코드를 최적화 해야 하는 상황 발생
- 성능에 관한 문제를 미리 염두해 두고 하위 호환성을 잘 유지하면서 성능을 개선할 수도 있도록 기반 만들기
- 성능을 개선한다는 이유로 API 본연의 모습을 훼손해서는 안 된다
- 대개, 좋은 설계는 좋은 성능을 이끌어 낸다
- API의 성능 개선 작업이 다른 부분에 영향을 미치지 않고 인터페이스도 변경하지 않도로 충분히 주의
* API 성능에 관한 요소
1. 컴파일 타임 속도
- API의 컴파일 속도는 클라이언트 프로그램의 컴파일 시간과 관련되며 이는 API 사용자의 생산성에 영향
2. 런타임 속도
- API 메서드를 호출하는 동안 발생하는 오버헤드 시간
- 개발한 메서드가 자주 호출되거나 매번 다른 크기의 입력 값이 전달 되어도 좋은 성능을 제공해야 한다면 고려
3. 런타임 메모리 오버헤드
- API 메서드를 호출하는 동안 발생하는 메모리 오버헤드
- 많은 객체가 생성되거나 메모리에 상주하는 경우 반드시 체크
- CPU 캐시 성능에 영향
4. 라이브러리 크기
- 클라이언트가 자신의 응용 프로그램에서 참조해야 하는 구현 코드의 크기
- 클라이언트 응용 프로그램이 사용하는 디스크와 메모리의 전체 용량에 영향을 미침
5. 시작 시간
- API 라이브러리를 로드하고 초기화하는데 걸리는 시간
- 템플릿 리솔루션, 미해결 심벌 바인딩, 정적 초기화 호출, 또는 라이브러리 경로 검색 등과 같은 것들이 영향
* 컴파일 시 성능 향상에 필요한 옵션들을 적용하거나 제외
- 컴파일러가 가진 옵션들 살펴보기
- 만약 dynamic_cast 연산자를 사용할 필요가 없다면 런타임 타입 정보(RTTI) 옵션을 꺼두는 것이 일반적
- 성능 최적화를 할 때 기억해야 할 것은 절대로 어느 부분이 느릴 거라는 직감이나 예상을 신뢰해서는 안됨
- 언제든 실제 환경에서 API의 성능 프로파일을 통해 결과를 측정
- 그 결과를 토대로 가장 영향이 큰 쪽에 초점을 맞춰 최적화를 진행
- 가장 쉬운 방법부터 적용한 후에 모든 기능이 제대로 동작하는 상태에서 어떤 부분을 최우선으로 최적화
* 암달의 법칙
- 시스템의 일부를 최적화해서 얻은 전체적인 성능은 개선된 시간의 일부로 제한
댓글