CODEWITHSUNDEEP
c++11vectorprofilinggprof
agenius5
agenius5

Reputation: 31

What are these c++ std functions in my gprof output which are taking quite a lot of time?

gprof output. I have used deques, std::vector and std::move in my code.

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 10.70      0.78     0.78 411724776     0.00     0.00  __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >::operator*() const
  5.97      1.22     0.44 114087996     0.00     0.00  __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >::operator--()
  5.90      1.65     0.43 256602502     0.00     0.00  __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >::base() const
  5.90      2.08     0.43 197352626     0.00     0.00  std::remove_reference<int&>::type&& std::move<int&>(int&)
  5.76      2.50     0.42    20556     0.00     0.00  void std::__move_merge_adaptive<int*, __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__ops::_Iter_less_iter>(int*, int*, __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__ops::_Iter_less_iter)
  5.49      2.90     0.40 139505351     0.00     0.00  __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >::operator++()

Upvotes: 1

Views: 591

Answers (2)

Mike Dunlavey
Mike Dunlavey

Reputation: 40679

I wish Vaughn were right, but in my experience it doesn't always work. In fact, from what I've seen, it almost never works. Since in a debug build you lose visibility into that code, the programmer's tendency is to just assume those things are inlined when chances are they are not. One way to check is to turn on optimization in an otherwise DEBUG build, and inspect the generated disassembly code.

It is often beyond the compiler's ability to figure out what the programmer intended, so it sticks to what's safe. Like for example the programmer may know that an array index is within the array bounds or is even constant, but that doesn't mean the compiler can figure it out.

This is an issue when you use standard library templates. I know people are encouraged to use them because they catch junior programming mistakes, but the price you pay for them doesn't go away.

Upvotes: 0

Vaughn Cato
Vaughn Cato

Reputation: 64308

These are functions which are implementation details of the standard library. Since you are profiling, you want to enable optimization in the compiler, since otherwise the compiler is basically paying no attention to trying to make your program run fast, it is just trying to make it easy to debug. Once you enable optimization you should see these functions disappear as the compiler realizes they can be inlined, removing the function call overhead.

Upvotes: 1

Related Questions