10. 문제점
● 느리다!
● 뭐라고 하는지 하나도 모르겠다.
● 뭐라고 나오긴 하는데, 너무 많이 나온다.
● 실제로 어디서 얼마만큼 걸렸는 지 짐작도 안
된다.
● python만 된다.
11. 필요한 것
● 문제점을 뒤집으면 필요한 것이 됨.
● 원하는 메소드의 시작 시간과 끝 시간을 알 수
있어야 한다.
● 쉽게 켜고 끌 수 있어야 한다.
12. 일반적인 측정 방식
def method1():
blahblah
return r
def method1():
start = time.time()
blahblah
end = time.time()
print 'method1()', start, end - start
return r
13. 일반적인 측정 방식
def method1():
blahblah
return r
@trace
def method1():
blahblah
return r
def trace(func):
def wrapper(*args, **kwds):
start = time.time()
r = func(*args, **kwds)
end = time.time()
print func.__name__ + ''()', start,
end - start
return r
return wrapper
15. 구현 노트
● 단순히 "MARK: xxx: some_method" 라는 파
일이름(?)으로 접근만 하면 된다.
16. 구현 및 시연
● 구현
○ https://github.com/ganadist/ptrace
17. 장점
● 구현이 간단
● 나름대로 portable
○ system call만 가로챌 수 있으면 됨.
○ 파싱하는 부분만 해당 OS의 형식에 따라 수정하면 완
료
18. 또 다른 문제점
● 여전히 느리다.
○ syscall hook 는 비용이 많이 든다.
● 많은 것을 표현하기 힘들다.
○ 이미지를 무한히 키울 수 없다.
● 호출 순서(call stack)를 확인하기 힘들다.
○ 1차원 적으로만 표현된다.
● 무엇때문에 거기서 시간을 쳐묵쳐묵 하는지
알 수가 없다.
○ 지정한 이벤트만 표시된다.
21. 구현 및 시연
● 구현
○ https://github.com/ganadist/systrace
22. 아직도 남은 문제점..
● 여전히 느리다.
○ 불확정성의 원리
○ 측정하려는 행위 자체가 측정을 부정확하게 만든다.
● 여전히 많은 것을 표현하기 힘들다.
○ 커널 메모리에 저장됨.
○ 무한히 데이터를 모을 수 없다.
○ 하지만 순간적인 상황에 대해서는 아주 유용하다.
● 특정 환경에서만 실행 가능
○ linux ftrace 기반
○ linux 2.6.33 이상에서 사용 가능
23. 그럼에도 불구하고.
● python profile api는 쓸만함.
○ 그리고 훨씬 빠른 cProfile
● profiler가 모든 것을 해결해주지 않음
○ 아무리 삽질하고 x랄을 떨어도 Fiat 500 이 Red
X1 가 될 수 없다.
■ 그대신 Fiat 500 을 Vettel 이 운전하는 효과는 누
릴 수 있음.
■ 해당 프로그램이 낼 수 있는 최대 속도를 짐작할
수 있게 해줌.
○ 필요할 때 적당한 도구를 써야.
○ 그리고 결국 분석 및 개선은 결국 사람이 해야 함.