Будет ли оптимизирована неэффективность операторов postfix ++ / - для итераторов STL? - PullRequest
Новая
       27

Будет ли оптимизирована неэффективность операторов postfix ++ / - для итераторов STL?

11 голосов
/ 21 июня 2011

Я знаю, что постфиксные версии операторов увеличения / уменьшения, как правило, будут оптимизированы компилятором для встроенных типов (т. Е. Копия не будет создаваться), но так ли это для iterator s?

Они, по сути, являются просто перегруженными операторами и могут быть реализованы любым количеством способов, но поскольку их поведение строго определено, может быть оптимизированными, и если да, то являются ли они какими-либо / многими компиляторами? 

#include <vector> 

void foo(std::vector<int>& v){
  for (std::vector<int>::iterator i = v.begin();
       i!=v.end();
       i++){  //will this get optimised by the compiler?
    *i += 20;
  }
}

1 Ответ

9 голосов
/ 21 июня 2011

В конкретном случае std::vector при реализации STL в GNU GCC (версия 4.6.1) я не думаю, что будет разница в производительности при достаточно высоких уровнях оптимизации.

Реализация для прямых итераторов на vector предоставляется __gnu_cxx::__normal_iterator<typename _Iterator, typename _Container>. Давайте посмотрим на его конструктор и постфикс ++ оператор: 

  explicit
  __normal_iterator(const _Iterator& __i) : _M_current(__i) { }

  __normal_iterator
  operator++(int)
  { return __normal_iterator(_M_current++); }

И его экземпляр в vector: 

  typedef __gnu_cxx::__normal_iterator<pointer, vector> iterator;

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

Но действительно ли это оптимизировано? Давайте разберемся. Тестовый код: 

#include <vector>

void test_prefix(std::vector<int>::iterator &it)
{
    ++it;
}

void test_postfix(std::vector<int>::iterator &it)
{
    it++;
}

Выходная сборка (на -Os): 

    .file   "test.cpp"
    .text
    .globl  _Z11test_prefixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE
    .type   _Z11test_prefixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE, @function
_Z11test_prefixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE:
.LFB442:
    .cfi_startproc
    pushl   %ebp
    .cfi_def_cfa_offset 8
    .cfi_offset 5, -8
    movl    %esp, %ebp
    .cfi_def_cfa_register 5
    movl    8(%ebp), %eax
    addl    $4, (%eax)
    popl    %ebp
    .cfi_def_cfa 4, 4
    .cfi_restore 5
    ret
    .cfi_endproc
.LFE442:
    .size   _Z11test_prefixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE, .-_Z11test_prefixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE
    .globl  _Z12test_postfixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE
    .type   _Z12test_postfixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE, @function
_Z12test_postfixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE:
.LFB443:
    .cfi_startproc
    pushl   %ebp
    .cfi_def_cfa_offset 8
    .cfi_offset 5, -8
    movl    %esp, %ebp
    .cfi_def_cfa_register 5
    movl    8(%ebp), %eax
    addl    $4, (%eax)
    popl    %ebp
    .cfi_def_cfa 4, 4
    .cfi_restore 5
    ret
    .cfi_endproc
.LFE443:
    .size   _Z12test_postfixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE, .-_Z12test_postfixRN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEE
    .ident  "GCC: (Debian 4.6.0-10) 4.6.1 20110526 (prerelease)"
    .section    .note.GNU-stack,"",@progbits

Как видите, в обоих случаях выводится одна и та же сборка.

Конечно, это не обязательно относится к пользовательским итераторам или к более сложным типам данных. Но, по-видимому, для vector префикс и постфикс (без захвата возвращаемого значения постфикса) имеют одинаковую производительность.

...