gprof messing up

Question

私は2つのプロファイルにcppコードを試しています。私は-pgフラグを付けてコンパイルし、出力を得るためにそれをプロファイリングした後、非常に奇妙な関数名を得ました。これは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) 

： これは私が使用していますメイクファイルである

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なのか？ C++で）=すべてのヘルプは大歓迎:)歓声で

Answer 1

私はgpr​​ofのとCに精通していますが、これは、CPP

と私の最初の出会いで、関数名は、彼らが属するクラス、その戻り値の型が含まれ、すべての引数型。これは名前を「mangling」することによって行われます。これは関数が異なる引数型で多重定義できるようにするためです。 gprofはそのことを認識しており、それらをアンマネーすることができます。

フラットプロファイルで見ていることは、PCがいくつかのクラスライブラリルーチンでキャプチャされることが多いことです。これは、呼び出しパスがコード内でどのようなものになって、それらのルーチンに終わるかという手がかりを与える場合にのみ役に立ちます。コールグラフ（計装）はそこに役立ちます。

もちろん、私はあなたがやりたいと思っていないI/Oを知りません。 ライブラリーでI/Oを深くしている時間の99％をプログラムが費やしている可能性があります。ライブラリーでは、それが起こっていないとわからず、gprofもありません。

Zoomをご覧ください。