Что это за функции c ++ std в моем выводе gprof, которые занимают довольно много времени?

Question

Gprof выходной. Я использовал deques, vector и std :: move в моем коде.

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++()

Answer 1

Это функции, которые являются деталями реализации стандартной библиотеки. Поскольку вы профилируете, вы хотите включить оптимизацию в компиляторе, так как в противном случае компилятор в основном не обращает внимания на попытки заставить вашу программу работать быстро, он просто пытается облегчить отладку. Как только вы включите оптимизацию, вы увидите, что эти функции исчезают, так как компилятор понимает, что они могут быть встроены, что устраняет накладные расходы на вызов функции.

Answer 2

Я sh Вон был прав, но по моему опыту это не всегда работает. Фактически, из того, что я видел, это почти никогда не работает. Поскольку в отладочной сборке вы теряете видимость этого кода, программист склонен просто предполагать, что эти вещи встроены, когда есть вероятность, что это не так. Один из способов проверки - включить оптимизацию в сборке DEBUG, и проверить сгенерированный код дизассемблирования.

Компилятору часто не удается понять, что задумал программист, поэтому он придерживается того, что безопасно. Например, программист может знать, что индекс массива находится в границах массива или даже является постоянным, но это не означает, что компилятор может это выяснить.

Это проблема, когда вы используете стандартные шаблоны библиотек. , Я знаю, что людям рекомендуется использовать их, потому что они ловят младшие ошибки программирования, но цена, которую вы платите за них, не go прочь.