티스토리 뷰
KOSTA <코드 최적화 전략 및 기법> 강의 내용의 일부분을 정리한 글입니다.
1. 프로그램 최적화 이해
최적화(Optimization) 정의
- 컴퓨터 과학에서 프로그램 최적화 또는 소프트웨어 최적화란 작업 효율을 높이거나 보다 적은 자원을 사용하도록 소프트웨어 시스템을 변경하는 작업 절차를 의미함.
- 최적화를 잘 수행하더라도 모두 상황에서 최적(optimal)인 시스템은 있을 수 없음.
- 수행 시간, 메모리, 저장소, CPU 등 어떤 자원에 우선순위를 두는가에 따라 최적화 방향을 달라질 수 있음.
- 따라서, 시스템의 환경과 목표를 이해하고, 다양한 트레이드-오프를 고려하여 최적화 작업을 수행해야 함.
- 효율적인 자원 구성과 사용으로 수행 성능(performance)이나 범위성(scalability) 등과 같은 품질 목표를 달성하는 것이 최적화의 궁극적인 목표임. 이것은 아키텍처 설계의 목표, 방향과 일치함.
최적화 수준
- 최적화는 다양한 수준(level)에서 이루어지며, 높은 수준일 수록 영향도가 크고 후에 변경이 어려움.
- 따라서 최적화는 위에서부터 아래로 진행을 하는 것이 보다 효율적임.
최적화(optimization)와 플랫폼
- 코드 최적화는 플랫폼 의존적인 것과 플랫폼 독립적인 것으로 분류할 수 있임.
- 플랫폼 독립적인 방식은 효율적일 수 있지만 최적화에 한계가 있임.
- 특정 속성이나 매개 변수를 상황에 맞추어 조정할 수 있는 플랫폼 의존적 방식이 고도의 최적화가 가능함.
병목 지점 찾기
"전체 결과의 80%가 원인의 20%에서 일어난다." - 빌프레도, 이탈리아 경제학자
최적화가 필요한 곳
"섣부른 최적화는 모든 악의 근원이다." - 도널드 커누스, 컴퓨터 과학자
전체적인 수행 성능 분석을 통해서, 구체적으로 어떤 부분에서 어떤 비효율이 있는 지 확인한 후에야, 최적화 작업 여부를 결정해야 한다. 설계->코딩-> 프로파일링->최적화 흐름을 따라 가기 위해서 단순한 설계(loose coupling, high cohesion)를 유지해야 함.
요약
- 운영 체제, 가상 머신, 컴파일러, 빌드 도구 등이 발전하면서 낮은 수준의 최적화 니즈는 줄어듬.
- 자원 비용의 비약적인 감소도 최적화를 바라보는 관점 변경
- 인적 자원 비용을 줄이되 물적 자원을 투입하는 방식으 로 최적화(문제를 해결)하는 경향이 있음.
"프로그램 최적화의 첫 번째 규칙은 '하지 말라'이다. 두 번째 규칙은 전문가만 최적화 작업을 하되, '아직은 이르니 하지 말라' 이다."
2. 아키텍처 레벨 최적화
최적화 포인트
- 목표 시스템의 성능과 복잡성 이슈는 소프트웨어 설계의 기본 규칙이 무너졌을 때 발생
- 소프트웨어의 설계 원칙인 SoC(Separation of Concerns) 관점으로 돌아가서 해결 방안을 마련해야 함.
- 비즈니스 로직은 high cohesion하고, 처리 대상 업무는 loose coupling하는 방식으로 개선
최적화 이미지
- 서비스 서버는 비즈니스 로직이라는 관심사를 한 곳에 모아서 처리하는 서버
- 외부에서 보면 (SOA의) 서비스로 보이고, 내부로 보면 비즈니스 컴포넌트
- 자원 접근 또는 데이터 매핑은 SQL을 최소화 하는 방향으로 개선
요약
- 아키텍처 레벨의 최적화가 필요한 상황에서 특정 대상을 최적화하는 것은 의미가 없을 수 있음.
- 아키텍처 레벨은 최적화 관점 보다는 올바른 설계 관점에서 접근하는 것이 바람직함.
- 아키텍처 레벨의 최적화 원칙: 관심사의 분리(Separation of Concerns)
- 최적화에 필요한 기술들
3. 모델 레벨 최적화
메소드의 복잡도(Cyclomatic Complexity) 줄이기
- 문제를 해결하기 위해서는 아이디어나 새로운 개념이 필요함. 코드 최적화 수준을 벗어날 필요함.
- 물론 현장에서는 새로운 아이디어나 개념이 필요없을 정도로 모든 것이 정교하게 정의되어 있음.
- 객체 모델 수준에서 문제를 풀어가기 위해 새로운 역할을 식별하고 역할 담당 객체를 등장 시킴.
4. 프로그램 레벨 최적화
요약
- 프로그래밍 레벨의 최적화는 대상은 자료 구조, 알고리즘, 객체 관계 등으로 매우 다양함.
- 프로그램을 단순하게 유지함으로써 유지보수를 용이하게 하고, 성능 최적화는 자원 활용 방법을 이용하여 풀어가는 것이 비즈니스 지원 애플리케이션 설계의 방향임.
예) 객체의 크기를 전혀 고려하지 않은 라이브러리 설계의 위험성
5. 정적분석도구: CodePro AnalytiX
개발자 자가 진단 요소
코드 중복
블록 깊이(Block Depth)
복잡성 (Cyclomatic Complexity)
메소드 평균 LoC(Lines of Code)
평균 매개변수 개수
의존관계 (dependency)
LOC
참고
SonarQube, http://www.sonarqube.org/
C++ 코드 품질 관리 비법, http://www.slideshare.net/sunhyouplee/c-33426459
에릭 에반스, <도메인 주도 설계>, 위키북스, 2011
- James Song
'Seminar' 카테고리의 다른 글
[Build2016]Building a Conversational Bot: From 0 to 60 (0) | 2016.07.25 |
---|---|
[Build2016]Building Desktop Apps in Visual Studio "15" (0) | 2016.07.21 |
Build 2011 <Moving driver quality upstream with WDK driver verification and test tools> (1) | 2016.02.14 |
TechDays 2015 <프로그래밍 언어의 F1머신 C++을 타고 Windows 10 UWP 앱 개발의 세계로~> (0) | 2016.02.08 |
TechDays 2015 <디버깅, 어디까지 해봤니? 당신이 아마도 몰랐을 디버깅 꿀팁 공개> (0) | 2016.01.22 |
- #cpp
- #techdays2015
- 상속
- #build2016
- #uwp
- Effective C++
- #스콧마이어스
- #레거시코드
- 객체 지향 설계
- #세미나
- Scott Meyers
- #알고리즘
- #ModernCPP
- #ndc
- #팀개발
- #mva
- #scottmeyers
- #마이클페더스
- #EffectiveModernCpp
- #임백준
- #클린코드
- #코드최적화
- #제럴드와인버그
- #csharp
- #로버트마틴
- #자녀교육
- #cplusplus
- 책
- #프로그래밍심리학
- Effective Modern C++
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |