关于linux:Golang:什么是etext?

Golang: What is etext?

我已经开始剖析我的一些Go1.2代码,并且最重要的项目始终是名为" etext"的东西。我进行了搜索,但是找不到其他有关它的信息,除了可能与Go例程中的调用深度有关。但是,我没有使用任何Go例程,并且'etext'仍然占总执行时间的75%或更多。

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

有人能解释一下这是什么吗?是否有办法减少影响?


我遇到了同样的问题,然后发现了这个问题:pprof在go 1.2中损坏了?为了验证它确实是一个1.2错误,我编写了以下" hello world"程序:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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。

您可以使用" go test –c"?斜嘁搿?使用" ./test.test -test.bench"运行。 -test.cpuprofile = test.prof"
使用"执行工具pprof test.test test.prof"查看结?/p>>

1
2
3
4
5
6
7
8
9
10
11
12
(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

>上面的结果是使用go 1.2.1获得的
然后,我使用go 1.1.1做了同样的事情,并得到以下结果?/p>>

1
2
3
4
5
6
7
8
9
10
11
12
(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结果看起来正确?/p>>

>因此,我确信这确实是一个1.2.1错误。我切换到实际项目中使用go 1.1.1,现在我对分析结果感到满意?/p>>


我认为Mathias Urlichs在您的cgo代码中缺少调试符号是正确的。值得注意的是,诸如net和syscall之类的一些标准pkg使用cgo。

如果您向下滚动到该文档的底部到"警告"部分,您会看到第三个项目符号显示...

If the program linked in a library that was not compiled with enough symbolic information, all samples associated with the library may be charged to the last symbol found in the program before the library. This will artificially inflate the count for that symbol.

我不是100%肯定这是正在发生的事情,但是我敢打赌这就是为什么etext看起来很忙的原因(换句话说,etext是各种功能的集合,有足够的信息供pprof正确分析。)。