gprof가 엉망이되었습니다

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이기 때문입니까? 나는 gprof의와 C 익숙하지만이

어떤 도움을 환영합니다 :) 환호 =)

Answer 1

, 함수 이름은 그들이 속한 클래스, 자신의 반환 형식을 포함하는 C++에서

이며 CPP와 나의 첫 만남이다 모든 인수 유형. 그것은 이름을 "맹 글링"하여 이루어집니다. 이것은 함수가 다른 인수 유형으로 오버로드 될 수 있기 때문입니다. gprof은 그 사실을 알고 있으며, 그것들을 언 매니지 할 수 있습니다.

평면 프로필에서 볼 수있는 것은 PC가 종종 일부 클래스 라이브러리 루틴에서 캡처된다는 것입니다. 이는 루틴이 끝나는 코드에서 호출 경로가 무엇인지 알 수있는 경우에만 유용합니다. 콜 그래프 (instrumentation)는 도움이됩니다.

그리고 당연히 당신이하고 싶지 않은 I/O는 눈이 멀었습니다. 프로그램이 라이브러리에서 I/O를 수행하는 데 소요되는 시간의 99 %를 소비 할 수 있습니다. 라이브러리에서 어떤 상황인지 모르는 경우도 있고 gprof도 그렇지 않은 경우입니다.

Zoom을 살펴보십시오.