使用GPerf工具:不工作，重定向问题吗？

Question

我试图分析我的软件，以优化它。

我在编译标志gprof中使用了-g -pg -O3，但是结果并没有给出足够的精度。

下面是我的编译跟踪：

$: make clean; make;

rm -f ./obj/*.o
rm -f ./bin/mdk-verifier
rm -f ./grammar/modal.output
rm -f ./grammar/modal.tab.h
rm -f ./grammar/*.cpp
rm -f ./lex.backup

bison -d -t -l -v -o ./grammar/modal.tab.c ./grammar/modal.y && mv ./grammar/modal.tab.c ./grammar/modal.tab.cpp
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./grammar/modal.tab.cpp -o ./obj/modal.tab.o
flex -l -b -o./grammar/lex.yy.cpp ./grammar/modal.lex   
g++ -O3 -g -pg -I./include -c ./grammar/lex.yy.cpp -o ./obj/lex.yy.o
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./src/Kripke.cc -o ./obj/Kripke.o   
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./src/Term.cc -o ./obj/Term.o 
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./src/BooleanConstant.cc -o ./obj/BooleanConstant.o 
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./src/Variable.cc -o ./obj/Variable.o 
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./src/PropositionalVariable.cc -o ./obj/PropositionalVariable.o 
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./src/Operation.cc -o ./obj/Operation.o 
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./src/BooleanOperation.cc -o ./obj/BooleanOperation.o 
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./src/ModalOperation.cc -o ./obj/ModalOperation.o   
g++ -O3 -g -pg -fPIC -std=c++11  -I./include -c ./src/Formula.cc -o ./obj/Formula.o 
g++ -O3 -g -pg -fPIC -std=c++11  -o ./obj/Main.o -c ./src/Main.cc 
g++ -O3 -g -pg -static -lprofiler -o ./bin/mdk-verifier ./obj/modal.tab.o ./obj/lex.yy.o ./obj/Kripke.o ./obj/Term.o ./obj/BooleanConstant.o ./obj/PropositionalVariable.o ./obj/Variable.o ./obj/Operation.o ./obj/BooleanOperation.o ./obj/ModalOperation.o ./obj/Formula.o ./obj/Main.o               

以下是我如何称呼我的程序：

$: ./bin/mdk-verifier ./problem.txt < solution.txt 

所以执行之后，一切都很好，我得到了一个gmon.out文件。我正在执行命令gprof ./bin/mdk-verifier | more，并得到以下结果：

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 34.00      2.13     2.13       18   118.33   118.33  ModalOperation::checkBranch(Kripke&, unsigned int)
  ...
  ...
  5.91      4.98     0.37 54684911     0.00     0.00  BooleanOperation::checkBranch(Kripke&, unsigned int)
  4.63      5.27     0.29 54684911     0.00     0.00  PropositionalVariable::checkBranch(Kripke&, unsigned int)

显然，ModalOperation的呼叫数：：校验分支溢出了.每次我进入这个功能时，我都会打超过18个电话.

所以我想用另一个更精确的分析器，我找到了谷歌的GPerfTools。

我想使用它，我安装在我的Ubuntu上：

• libgoogle-perftools dev
• google-完善工具

通过遵循教程，他们要求我设置环境变量CPUPROFILE

我做到了我得到了：

 $: env | grep "CPU"
 CPUPROFILE=./prof.out

我还在可执行文件的链接过程中放置了-lprofiler，所以我认为一切正常，我可以开始分析文件./prof.out中的数据。

但不幸的是，这个文件没有出现..。什么都没有被创造，所以我不能分析任何东西.

有没有人知道为什么没有创建./prof.out文件，为什么分析没有收集数据？

提前感谢您的帮助！

最诚挚的问候；

Answer 1

你的目的是在你的软件中节省时间。多个问题，首先是负面因素：

• -O3:编译器可以优化某些事情。它不能优化只有你才能优化的东西。它所能做的就是通过对代码进行置乱，使它们很难找到。使用-O3的时间是在您找到并修复了所能做的事情之后。
• gprof是值得尊敬的，但仅此而已。它对程序计数器进行采样并对函数调用进行计数。https://stackoverflow.com/a/1779343/23771 --它确实给出了一个调用图，但是https://stackoverflow.com/a/25870103/23771。
• gperftools更好(为了回应Aliaksei的评论)，因为它是一个真正的堆栈取样器。通常情况下，它是一个“CPU-分析器”，在这种模式下，它对阻塞所花费的任何时间都是盲目的，比如I/O或睡眠。但是，如果您设置了环境变量https://gperftools.googlecode.com/svn/trunk/doc/cpuprofile.html，您可以让它在挂钟时间进行采样，这样它就会看到I/O、休眠和其他阻塞系统调用。它有许多输出选项。它似乎不容易看到一个小的随机选择的实际堆栈样本本身，与行号信息。

现在是积极的方面：

• 有一种方法(不是产品)是许多人使用的，https://stackoverflow.com/a/378024/23771。其思想是用质量来代替数量--在正确的时间得到堆栈样本。在感兴趣的时间间隔内很少需要，如5、10或20。如果某件事花费了95%的时间，那么每个堆栈样本都有95%的机会在正确的时间出现。然后检查每个堆栈示例，看看发生了什么--不要仅仅总结/累积/平均/假装统计数据。(如果这是在调试器下手动完成的，您还可以检查数据变量，从而更好地理解程序为什么要花费时间。)目的是找出问题，而不是测量它。任何你可以避免的东西，如果你在一个以上的样本上看到它，将节省大量的时间。https://scicomp.stackexchange.com/a/2719/1262你需要看两次它的样本越少，它就会保存得越多。如果您想确切地看到它拯救了您，只需使用秒表之前和之后。别只做一次。每次修复问题时，都会发现更多的问题，因此，如果您继续这样做，可能会得到https://softwareengineering.stackexchange.com/a/302345/2429。