2012-04-29 2 views
0

꽤 많은 비용이 드는 작업을 수행하는 보조 함수가 있습니다.함수를 만들기위한 gettimeofday/settimeofday가 시간이 걸리지 않는 것처럼 보임

알고리즘의 주요 섹션을 프로파일하려고하지만이 보조 함수가 많이 호출됩니다. 결과적으로, 측정 된 시간은 보조 기능의 시간을 고려합니다.

이 문제를 해결하기 위해 보조 기능이 즉각적으로 나타나도록 시간을 설정하고 복원하기로 결정했습니다. 다음 매크로를 정의했습니다 :

#define TIME_SAVE struct timeval _time_tv; gettimeofday(&_time_tv,NULL); 
#define TIME_RESTORE settimeofday(&_time_tv,NULL); 

. . . 보조 기능의 첫 번째 줄과 마지막 줄로 사용했습니다. 그러나 어떤 이유로 보조 함수의 오버 헤드가 여전히 포함되어 있습니다!

그래서 저는 이것이 다소 엉뚱한 해결책이라는 것을 알고 있습니다. 그래서 나는 계속 나아갔습니다.하지만이 아이디어가 효과가 없었던 이유에 대해서는 여전히 궁금합니다. 누군가 설명 할 수 있습니까?

+1

프로파일 러를 사용하십시오. – orlp

+0

나머지 시간은 어떻게 측정합니까? – talonmies

답변

0

몇 가지 가능성이 있습니다. 하나는 리눅스가 시계를 정확하게 유지하려고 시도하고 시계에 대한 조정이 시스템 내에서 원활한 시간 감각을 유지하기 위해 '부드럽게'또는 '수정'될 수 있다는 것입니다. NTP를 실행하는 경우에도 합리적인 시간 감각을 유지하려고합니다.

내 접근 방식은 시계를 수정하지 않고 대신 프로세스의 각 부분에서 소요되는 시간을 추적하는 것이 었습니다. 값 비싼 부분에 대한 호출은 누적 될 것입니다 (진입 및 종료시 gettimeofday를 구하고 누적하여). 그리고 전체 시간에서 그 값을 뺍니다. 더 좋은 방법에 대한 다른 가능성이 있습니다.

4

이런 식으로 프로파일 링을 원하면 은 시스템 시계를 설정하지 마십시오. 당신이 그것을 할 수있는 권한이 있다면 이것은 모든 종류의 것들을 망칠 것입니다. 기본적으로 당신은 settimeofday에 대해 들어 본 적이 있다는 것을 잊어야합니다. 당신이 원하는 것은 측정에서 제외시키고 자하는 기능의 전후에 gettimeofday으로 전화해서 그 차이를 계산하는 것입니다. 그런 다음이 기능에 소요 된 시간을 전체 시간에서 제외 할 수 있습니다.

이와 같이 "프로파일 링"의 전체적인 방법은 매우 결함이 있습니다. gettimeofday (1)은 측정하려고하는 것과 비교할 때 상당한 시간이 걸리기 때문에 (2) 아마도 kernelspace를 사용하면 프로그램의 캐시 일관성에 심각한 손상을 줄 수 있습니다. 이 두 번째 문제점은 프로그램의 성능 특성을 실제로 관찰하려고 시도 할 때 실제로 문제를 변경하는 것이 가장 문제가되는 것입니다. 당신이 정말로 무엇을해야

비슷한 oprofile 또는 perf 또는 무언가를 사용하는 대신이 프로파일의 종류 (gettimeofday 또는 GCC의 -pg/gmon 프로파일)에 대해 잊고있다. 이러한 최신 프로파일 링 기술은 통계적으로 명령 포인터를 샘플링하고 정보를 주기적으로 샘플링하여 작동합니다. 프로그램 자체의 코드는 전혀 수정되지 않으므로 가능한 한 프로파일 러가 실행되지 않는 방식으로 동작합니다.

+0

요즘'gettimeofday()'는 종종 "vsyscall"처럼 kernelspace로 전환하지 않고 처리 될 수 있습니다. – caf

+0

@caf : 내가 할 수있는 유일한 시스템은 Linux/x86_64입니다. 내가 아는 한, 다른 모든 OS 및 Linux의 모든 다른 CPU 아치에는 시스템 호출이 필요합니다. –

관련 문제