gprof搞砸

我正在尝试2个配置文件cpp代码。我使用-pg标志进行编译，在对其进行分析以获得输出后，我得到了一些非常奇怪的函数名称。这是我使用make文件：gprof搞砸

# Makefile for parallel simulated annealer 

PREFIX=${PARSECDIR}/pkgs/kernels/canneal/inst/${PARSECPLAT} 

TARGET=canneal 
LIBS:=$(LIBS) -lm 

CXXFLAGS+=-pg 

ifdef version 
    ifeq "$(version)" "pthreads" 
    CXXFLAGS+=-DENABLE_THREADS -pthread 
    endif 
endif 

all: 
    $(CXX) $(CXXFLAGS) annealer_thread.cpp -c -o annealer_thread.o 
    $(CXX) $(CXXFLAGS) rng.cpp -c -o rng.o 
    $(CXX) $(CXXFLAGS) netlist.cpp -c -o netlist.o 
    $(CXX) $(CXXFLAGS) main.cpp -c -o main.o 
    $(CXX) $(CXXFLAGS) netlist_elem.cpp -c -o netlist_elem.o 
    $(CXX) $(CXXFLAGS) $(LDFLAGS) *.o $(LIBS) -o $(TARGET) 

clean: 
    rm -f *.o $(TARGET) 

install: 
    mkdir -p $(PREFIX)/bin 
    cp -f $(TARGET) $(PREFIX)/bin/$(TARGET)

这是gprof的输出的一个示例：

Flat profile: 

Each sample counts as 0.01 seconds. 
    % cumulative self    self  total   
time seconds seconds calls s/call s/call name  
11.21  0.73  0.73 2800002  0.00  0.00 std::_Rb_tree<std::string, std::pair<std::string const, netlist_elem*>, std::_Select1st<std::pair<std::string const, netlist_elem*> >, std::less<std::string>, std::allocator<std::pair<std::string const, netlist_elem*> > >::_M_lower_bound(std::_Rb_tree_node<std::pair<std::string const, netlist_elem*> >*, std::_Rb_tree_node<std::pair<std::string const, netlist_elem*> >*, std::string const&) 
10.45  1.41  0.68 5856992  0.00  0.00 atomic_load_acq_int(unsigned int volatile*) 
    8.76  1.98  0.57 400001  0.00  0.00 netlist_elem::routing_cost_given_loc(location_t)

而这些文件中的真正的功能名称：

void annealer_thread::Run()

任何标志即时忘记？为什么分析还会显示函数的参数？是因为他们是班级吗？是因为它是cpp吗？我熟悉gprof的和c，但是这是我与CPP第一次遇到

欢迎任何帮助:)欢呼=）

来源

2011-01-25 Syntax_Error

像往常一样，在一个非平凡的程序中，CPU时间主要花费在库例程中，这并不能告诉你他们是如何被调用的。即使你得到这些问题的答案，[用gprof你可能会有更多的问题]（http://stackoverflow.com/questions/1777556/alternatives-to-gprof/1779343#1779343）。 – 2011-01-25 13:20:27

在C++中，函数名包括他们所属的阶层，他们的返回类型，所有的参数类型。这是通过“改变”名称来完成的。这是因为函数可以用不同的参数类型重载。 gprof意识到这一点，并可以解开它们。

你在平面配置文件中看到的是PC常常被捕获到某些类库例程中。这只有在它能够让你知道代码中的调用路径在那些例程中结束时才有用。调用图（仪表）在这里有一些帮助。

当然，对于任何你不想做的I/O都是盲目的。该程序可能花99％的时间在图书馆深入I/O，在那里你不知道它正在发生，gprof也没有。请参阅Zoom。

来源

2011-01-25 16:24:24

我该如何解开它们？我厌倦了'T'的旗帜，我认为它奏效了。你有其他想法吗？ – 2011-01-25 16:58:09

回答

相关问题