gprof로 프로파일하기를 원하는 프로그램이 있습니다. 문제는 소켓을 사용한다는 것입니다. 그래서 나는 다음과 같은 것을 얻습니다 :gprof를 소켓에 사용하기
::select(): Interrupted system call
나는이 문제를 잠시 동안 뒤로 돌리고, 포기하고, 계속 전진했습니다. 그러나 가능한 경우 gprof를 사용하여 코드를 프로파일 링 할 수 있기를 정말로 원합니다. 내가 무엇을 할 수 있을지? 내가 누락 된 gprof 옵션이 있습니까? 소켓 옵션? 이러한 유형의 시스템 호출이있을 경우 gprof는 전혀 쓸모가 없습니까? 그렇다면 실행 가능한 대안이 있습니까?
편집 : 플랫폼 :
이 이gprof를
if (errno == EINTR) { ...
각 시스템 호출 이후.
배경을 보시려면, 예를 들어 here을보십시오.
좋습니다. 후속 조치 : http://stackoverflow.com/questions/2958114/handling-eintr-with-goto –
gprof (here's the paper)은 신뢰할 만하지만이 경우에도 only was ever intended to measure changes이며 심지어 CPU 관련 문제 만 측정합니다. 문제를 찾는데 유용하다고 광고 한 적은 없습니다. 그것은 다른 사람들이 그것 위에 겹쳐진 아이디어입니다.
this method을 고려하십시오.
또 다른 좋은 옵션은 돈을 쓰지 않아도된다면 Zoom입니다.
추가 : 방금 예제를 제공 할 수 있습니다. Main이 A를 몇 번 호출하고, A가 B를 몇 번 호출하고, B가 C를 몇 번 호출하고, C가 소켓이나 파일을 사용하여 일부 I/O를 기다리는 호출 계층이 있다고 가정 해 보겠습니다. 기본적으로 모두 프로그램은 않습니다. 이제, 각 루틴이 다음 호출을 호출하는 횟수가 실제로 필요한 것보다 25 % 이상 더 많다고 가정하십시오. 1.25^3은 약 2이므로 전체 프로그램이 실제로 실행하는 데 2 배의 시간이 걸립니다.
처음에는 모든 시간이 I/O를 기다리는 데 소비되므로 gprof는 "실행"시간 만보고 있기 때문에 gprof는 그 시간이 어떻게 소비되었는지에 관해 알려주지 않습니다.
둘째로, (단지 인수로) 이이 I/O 시간을 계산했는지 가정합니다. 그것은 기본적으로 각 루틴이 100 % 시간이 걸린다는 콜 그래프를 줄 수 있습니다. 그게 당신에게 무엇을 말합니까? 당신이 이미 알고있는 것 이상은 없습니다.
그러나 작은 수의 스택 샘플을 가져 오는 경우 각 루틴에서 다음 샘플을 호출하는 코드 행을 볼 수 있습니다. 즉, 단지 대략적인 시간 추정치를 제공하는 것이 아니며 코드의 특정 라인을 가리키는 코드는 입니다. 각 코드 행을보고 더 적은 횟수로 코드를 수행 할 수 있는지 묻습니다. 당신이 이것을한다고 가정하면, 당신은 2 speedup의 요소를 얻을 것이다.
사람들은 이런 식으로 큰 요인을 얻습니다. 내 경험상 통화 수준은 쉽게 30 이상이 될 수 있습니다. 모든 전화 은 피해야하는지 물어볼 때까지으로 보입니다. 소수의 피할 수있는 전화조차도 많은 계층에 큰 영향을 줄 수 있습니다.
난 당신이 또한 당신의 플랫폼을 언급해야한다고 생각 : OS, 컴파일러, gprof은 버전 등 –
을이 글을 발견 : http://unix.derkeiler.com/Newsgroups/comp.unix : 어쩌면 일부 사용의의 .programmer/2004-03/0938.html – LoudNPossiblyWrong
프로필 작성에 valgrind/kcachegrind를 사용해 보셨나요? 나는 gprof에 그것을 선호한다. –