Golang：什么是etext？

我已经开始剖析我的一些Go1.2代码，并且顶部项目总是被命名为'etext'。我搜索了四周，但找不到关于它的很多信息，除了它可能与Go例程中的调用深度有关。但是，我没有使用任何Go例程，'etext'仍占总执行时间的75％或更多。Golang：什么是etext？

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

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

来源

2014-01-23 Bill

这似乎是相关的：https://groups.google.com/d/topic/golang-nuts/KEkZ0-t4Bu0/discussion显然它有事情做，在OSX中的错误。 – MatrixFrog

这也可能是相关的：http://grokbase.com/t/gg/golang-nuts/13chm1zt6a/go-nuts-a-performance-degradation-with-go-1-2 – Agis

是啊，我发现这两个的但我正在分析Linux，所以第一篇文章不适用，我没有使用函数文字或递归很多，所以我看不到第二篇文章会如何应用。 – Bill

我打的是同样的问题，后来我发现这一点：pprof broken in 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。

你可以编译这个“去测试-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的结果没有多大意义。系统调用和etext占用大部分时间。 1.1.1的结果看起来不错。

所以我相信这是一个真正的1.2.1错误。我转而在我的真实项目中使用go 1.1.1，现在我对分析结果感到满意。

来源

2014-05-03 14:51:07

伟大的工作。感谢分享。 – Xeoncross

这看起来像是正确的答案。在我的测试中看到类似的结果。 – Bill

我觉得马蒂亚斯Urlichs是正确的关于您的CGO代码所缺少调试符号。值得注意的是，像net和syscall这样的标准pkgs使用cgo。

如果您向下滚动到这个doc到所谓的注意事项段的底部，你可以看到，第三项说...

如果在一个库连接的程序，没有足够的编译符号信息时，与库相关的所有样本可能会被收取到库之前程序中找到的最后一个符号。这将人为地夸大该符号的计数。

我不是100％正面这是发生了什么，但我敢打赌，这就是为什么etext显得如此繁忙（换句话说，etext是各种功能的集合，没有足够的信息让pprof正确分析）。

来源

2014-02-08 13:24:31

Golang：什么是etext？

回答

相关问题