Golang: What is etext?

Question

我已经开始介绍我的一些go1.2代码，而顶部项目始终是名为'etext'的东西。我已经四处搜索，但找不到太多有关它的信息，除了它可能与GO例程中的呼叫深度有关。但是，我没有使用任何GO例程，而" Etext"仍在占用总执行时间的75％或更多。

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

任何人都可以解释这是什么，如果有任何方法可以减少影响？

Answer 1

我遇到了相同的问题，然后我发现了这一点：pprof of go 1.2？要验证这确实是一个1.2错误，我写了以下" Hello World"程序：

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"请参阅" Go Tool 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

上述结果是使用GO 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，现在我对分析结果感到满意。

Answer 2

我认为Mathias Urlichs在您的CGO代码中缺少调试符号是正确的。值得注意的是，某些标准PKG（例如NET和SYSCALL）使用CGO。

如果您向下滚动到该文档的底部到称为警告的部分，则可以看到第三个子弹说...

如果在库中链接的程序未包含足够的符号信息，则可能会将与库相关联的所有示例收取到库之前的程序中的最后一个符号。这将人为地夸大该符号的数量。

我不是100％肯定的，这是发生的事情，但我敢打赌，这就是为什么etext似乎如此忙（换句话说，etext是各种功能的集合正确分析。）。