파이콘 2015 정리 글이라고 해놓곤 일요일엔 집에 내려가야 되서 못갑니다...
누군가 나의 의지를 이어줘...
토요일 ¶
- 11:00 Python Test 시작하기
- unitest 소개
- mock 소개: 의존성을 가지는 코드 관련 테스트 툴
- docker 소개: 통합 테스트 관련
- selenium: 웹 ui관련 테스트 툴
- 웹 테스트를 할 때 필요한 소스는 미리 만들어 놓거나,
위의 docker를 이용할 수도 있음
메인 로직은 반드시 검증 < 테스트 시간 < 개발시간의 두 배위의 docker를 이용할 수도 있음
가능한 한 자주 테스트를 실행
- 테스트 규칙
시간 측정을 직접 해서 예외를 띄울 수밖에 없다고 함
한번에 하나만 테스트
실패가 명확해야 함
빠르게 테스트 되어야 함
중복 되지 않음
자동화
다른 것에 영향받지 않아야 함
성능에 관한 테스트는 unitest를 사용해야 하는 것이 아닌 실패가 명확해야 함
빠르게 테스트 되어야 함
중복 되지 않음
자동화
다른 것에 영향받지 않아야 함
시간 측정을 직접 해서 예외를 띄울 수밖에 없다고 함
- 12:00 Writing fast
- 컴퓨터와 파이썬 내부 이해
- 프로파일링으로 핫스팟 찾기
- 개선 -> 빠른 코드
- 빠르면서도 느린 컴퓨터
- 잘 모르겠지만 프로파일링이 좋음
- 빠른 코드 짜고 싶다
컴퓨터는 빠른듯 느리다
메모리의 속도:
메모리의 속도:
일반적인 인터페이스 < 메모리 전송 속도 < cpu와 관계된 버스나 특수한 버스
CPU 클럭: CPU가 무엇을 한번 하는데 걸리는 시간(hz)프로그램에 끝내는 데 필요한 클럭을 줄이는게 빠른 실행의 조건
dis: 파이썬 디스어셈블러
빠른 코드와 느린 코드는 실행되는 명령어 개수에 차이가 남
dis: 파이썬 디스어셈블러
빠른 코드와 느린 코드는 실행되는 명령어 개수에 차이가 남
프로파일러
- timeit: 여러번 돌려서 실행 시간 측정, 기본값으로 gc를 끔
- cProfile: 오버헤드 좀 있음, 대신 정보량이 많음
- line_profiler
- profiling: 실시간 프로파일링
- timeit: 여러번 돌려서 실행 시간 측정, 기본값으로 gc를 끔
- cProfile: 오버헤드 좀 있음, 대신 정보량이 많음
- line_profiler
- profiling: 실시간 프로파일링
빠른 코드를 짜면 CPU에 낭비되는 시간이 줄어든다.(CPU의 5초는 사람의 약 30000년)
- 14:00 파이썬 메모리 이모저모
id(obj): 해당 객체, 변수의 메모리 주소값 반환(C언어의 &연산자)
비교 연산자 is와 ==:
is는 같은 메모리 주소를 참조하는가
==는 같은 값을 가지고 있는가
is가 더 빠름, 하지만 is는 오버라이드 불가능
mutable: 공간을 새로 할당하지 않고 기존 메모리 공간을 변경하는 객체==는 같은 값을 가지고 있는가
is가 더 빠름, 하지만 is는 오버라이드 불가능
(set, list, dict...)
immutable: 기존값 변경 불가, 객체 값 변경 시 메모리 재할당
(int, float, string...)
mutable한 객체를 복제하는 법은 =이 아닌
(True, False, None, ..., notImplement...)
- list의 경우 slice 이용
- copy()이용
-> 단, 얕은 복사이므로 객체 안의 변수의 경우는 주소만 복제함.
(True, False, None, ..., notImplement...)
String interning: 문자열은 메모리에 한 번만 저장, 다음에 같은 문자열을
쓸 경우 이전의 문자열의 주소값을 줌. sys.intern()
쓸 경우 이전의 문자열의 주소값을 줌. sys.intern()
del 연산자: 강제로 객체를 지우는 방법
Reference count: 특정 메모리를 참조하는 수가 0이 될 경우, gc가 자동으로
제거
제거
Garbage Collection: 필요 없는 메모리 자동 해제, 휴리스틱이나 레퍼런스 카운터
이용
Generation을 나눠서 관리, 특정 threshold가 존재, 가장 낮은 Generation부터 GC
(각각의 Generation마다 메모리 한계치 존재, 한계가 올 때, GC가 작동함.
메모리 해제를 할 때, 먼저 만들어진 객체가 더 쓰레기일 확률이 높다고 생각하고
먼저 제거 대상이 됨.)
이용
Generation을 나눠서 관리, 특정 threshold가 존재, 가장 낮은 Generation부터 GC
(각각의 Generation마다 메모리 한계치 존재, 한계가 올 때, GC가 작동함.
메모리 해제를 할 때, 먼저 만들어진 객체가 더 쓰레기일 확률이 높다고 생각하고
먼저 제거 대상이 됨.)
module weakref: 참조하더라도 레퍼런스 카운트를 올리지 않음, 메모리에 자주 사용하진
않지만 필요할 땐 쓰는 데이터에 사용(이미지 캐싱)
않지만 필요할 땐 쓰는 데이터에 사용(이미지 캐싱)
monkey patch: 런타임시 실시간으로 클래스나 함수 등을 교체(module과 class 또한 파이썬에선 변수),
이를 통해 빌트인(기본적으로 제공되는) 클래스 등을 자기가 새로 만든 클래스 등으로 교체가 가능하다.
이를 통해 빌트인(기본적으로 제공되는) 클래스 등을 자기가 새로 만든 클래스 등으로 교체가 가능하다.
파이썬 성능 개선하는 소소한 팁
실행되고 있는 내용이 다른 게임서버에는 적합하지 않았음
또한 실행된 함수이름 하나만 불러와서 어디서 온 함수인지 확인하지
못했음
- String concatenate를 피해야 한다: string은 immutable이기 때문(map이나 fommater등을 사용해야 한다.)
- iterating 도중에 값을 바꾸는 건 되도록 복사를 먼저하자
- with 구문을 사용하자
- iterating 도중에 값을 바꾸는 건 되도록 복사를 먼저하자
- with 구문을 사용하자
- 15:00 파이썬을 이용한 OIS 시뮬레이션
뭔줄 모르고 들왔는데 대학원 내용이에요... 그래서 참고하지 말길 바랍니다...
OIS: 사람의 손떨림이 반영되는 카메라의 경우, 같은 이미지가 다른 위치에 - 17:00 Profiling 실시간 대화식 프로파일링
게임 개발 중 CPU 병목을 찾기 위해 개발
맺혀 발생하는 블러가 생길 수 있다. 이를 억제하기 위해 렌즈를 움직여서
같은 위치에 맺혀 블러를 없애는 기술이다.
시뮬레이션을 해야되는 이유:
- 확인샘플을 제작할 필요 없이, 다양한 조건과 조합으로 모듈의 성능을 검증할 수 있음.
- 사진 시뮬레이션이나 그래프로 테스트 확인 가능
- 특정 오차 내라면, 더 양산하기 쉬운 제품 선정 가능
Python-control: 교육 목적으로 제작된 라이브러리
시스템 설명: 전달함수, 딜레이, 자이로 센서, 엑츄에이터 설명
블록 다이어그램의 각각의 결과값을 직렬, 병렬 등에 따라 연산 함수로 이음(함수 제공됨)
절대 손떨림값/추적 오차로 OIS 성능 측정
비선형 시스템은 지원되지 않는 등의 점을 고려
이벤트 기반 프로파일링
- 함수 호출/반환 이벤트 추적
- 실행시간,호출 횟수를 조사
기존 프로파일러는 코루틴을 지원하지 않거나 실시간으로- 함수 호출/반환 이벤트 추적
- 실행시간,호출 횟수를 조사
실행되고 있는 내용이 다른 게임서버에는 적합하지 않았음
또한 실행된 함수이름 하나만 불러와서 어디서 온 함수인지 확인하지
못했음
프로파일링은
- 콜스택 계층구조를 보존해서 어느 기능에서 싫행된 함수인지 추적가능
- gevent와의 호환성 확보(코루틴의 성능 제대로 측정해냄)
- 대화식 뷰어: Urwid를 가져와서 콜스택을 키보드로도 접었다가 펼 수 있는
- 콜스택 계층구조를 보존해서 어느 기능에서 싫행된 함수인지 추적가능
- gevent와의 호환성 확보(코루틴의 성능 제대로 측정해냄)
- 대화식 뷰어: Urwid를 가져와서 콜스택을 키보드로도 접었다가 펼 수 있는
친화적인 뷰어 탑재
- 실시간 프로파일링하지만 너무 느림
그래서 통계적 프로파일링(단순히 실행하는 부분이 어느정도를 점유하고
있는 지만 조사)기능도 같이 도입 -> 샘플링을 통해 분기마다 분석하는 방식
있는 지만 조사)기능도 같이 도입 -> 샘플링을 통해 분기마다 분석하는 방식
프로파일링 사용방법 소개
깃허브 저장소(현재 개발중): what-studio/profiling
