2014-01-23 3 views
10

Go2.2 코드 중 일부를 프로파일 링하기 시작했으며 최상위 항목은 항상 'etext'라는 이름입니다. 나는 주변을 수색했으나 Go 루틴에서 호출 깊이와 관련된 것 이외의 많은 정보를 찾을 수 없었다. 그러나 나는 Go 루틴을 사용하지 않고 'etext'는 전체 실행 시간의 75 % 이상을 차지합니다.골란 : etext 란 무엇입니까?

(pprof) top20 
Total: 171 samples 
    128 74.9% 74.9%  128 74.9% etext 

영향을 줄이려면 어떤 방법이있을 수 있습니까?

+0

관련성이 있습니다. https://groups.google.com/d/topic/golang-nuts/KEkZ0-t4Bu0/discussion 분명히 OSX의 버그와 관련이 있습니다. – MatrixFrog

+0

다음과 관련이있을 수도 있습니다. http://grokbase.com/t/gg/golang-nuts/13chm1zt6a/go-nuts-a-performance-degradation-with-go-1-2 – Agis

+2

그래, 하지만 리눅스에서 프로파일 링을하고있어 첫 번째 기사는 적용되지 않으며 함수 리터럴이나 많은 재귀를 사용하지 않으므로 두 번째 방법을 적용 할 수 없습니다. – Bill

답변

3

다음과 같은 문제가 발생했습니다. pprof broken in go 1.2?.

package main 

import (
    "fmt" 
    "testing" 
) 

func BenchmarkPrintln(t *testing.B){ 
    TestPrintln(nil) 
} 

func TestPrintln(t *testing.T){ 
    for i := 0; i < 10000; i++ { 
      fmt.Println("hello " + " world!") 
    } 
} 

당신이 그것을 볼 수 있듯이 만 fmt.Println를 호출 정말 내가 다음에 "Hello World"프로그램을 작성 1.2 버그가 있는지 확인합니다.

"go test -c"로 컴파일 할 수 있습니다. "./test.test -test.bench"로 실행하십시오. -test.cpuprofile = test.prof " 와 결과 페이지의"도구 이동을 pprof test.test test.prof "

(pprof) top10 
Total: 36 samples 
    18 50.0% 50.0%  18 50.0% syscall.Syscall 
    8 22.2% 72.2%  8 22.2% etext 
    4 11.1% 83.3%  4 11.1% runtime.usleep 
    3 8.3% 91.7%  3 8.3% runtime.futex 
    1 2.8% 94.4%  1 2.8% MHeap_AllocLocked 
    1 2.8% 97.2%  1 2.8% fmt.(*fmt).padString 
    1 2.8% 100.0%  1 2.8% os.epipecheck 
    0 0.0% 100.0%  1 2.8% MCentral_Grow 
    0 0.0% 100.0%  33 91.7% System 
    0 0.0% 100.0%  3 8.3% _/home/xxiao/work/test.BenchmarkPrintln 

위의 결과는 내가 사용하여 동일한 일을 한 다음 1.2.1 이동 사용 받고 있습니다 1.1.1로 이동하여 다음 결과를 얻었습니다.

(pprof) top10 
Total: 10 samples 
    2 20.0% 20.0%  2 20.0% scanblock 
    1 10.0% 30.0%  1 10.0% fmt.(*pp).free 
    1 10.0% 40.0%  1 10.0% fmt.(*pp).printField 
    1 10.0% 50.0%  2 20.0% fmt.newPrinter 
    1 10.0% 60.0%  2 20.0% os.(*File).Write 
    1 10.0% 70.0%  1 10.0% runtime.MCache_Alloc 
    1 10.0% 80.0%  1 10.0% runtime.exitsyscall 
    1 10.0% 90.0%  1 10.0% sweepspan 
    1 10.0% 100.0%  1 10.0% sync.(*Mutex).Lock 
    0 0.0% 100.0%  6 60.0% _/home/xxiao/work/test.BenchmarkPrintln 

1.2.1 결과가 의미가 없다는 것을 알 수 있습니다. Syscall과 etext는 대부분 시간을 소비합니다. 그리고 1.1.1 결과는 옳았다.

그래서 나는 그것이 1.2.1 버그라고 확신합니다. 그리고 실제 프로젝트에서 1.1.1을 사용하도록 전환했으며 지금 프로파일 링 결과에 만족합니다.

+0

위대한 작품. 공유해 주셔서 감사합니다. – Xeoncross

+0

올바른 답변입니다. 내 테스트에서 비슷한 결과를 보았다. – Bill

2

Mathias Urlichs는 Cgo 코드에서 디버깅 기호가 누락되었다고 생각합니다. net과 syscall과 같은 표준 패키지는 cgo를 사용한다는 점에 유의할 가치가 있습니다. 당신이주의 사항라는 섹션이 doc의 맨 아래로 스크롤하면이 세 번째 글 머리 기호는 말한다 것을 볼 수 있습니다

...

하면 충분히 컴파일되지 않은 라이브러리에 링크 된 프로그램 상징적 인 정보의 경우 라이브러리와 관련된 모든 샘플은 라이브러리 이전의 프로그램에서 발견 된 마지막 심볼에 부과 될 수 있습니다. 그러면 인위적으로 해당 기호의 수가 증가합니다.

나는이 일어나고하지만 난 etext가 충분한 정보를 가지고 있지 않는 다양한 기능의 모음입니다 etext 즉 (너무 바빠서 것으로 보인다 이유가 있음을 베팅하고있어 100 % 긍정적 인 아니에요 pprof가 제대로 분석되도록합니다.).