Является ли преждевременной оптимизацией использование std :: move()?

Question

Предположим, у меня есть следующий код:

int main() 
{ 
    std::vector<std::string> strs; 

    std::string var("Hello World"); 
    // Make some modifications to 'var' 
    strs.push_back(std::move(var)); 
} 

Часть образца, я хочу отметить, является использование std::move(). В основном меня беспокоит копия на звонок push_back(). Предположим, что строка, которую я добавляю, действительно большая. Я все еще изучаю C++ 11 r-value-ссылки, поэтому я не уверен, как компилятор будет оптимизировать копию (если вообще) без std::move().

Может ли кто-нибудь объяснить, является ли это преждевременной оптимизацией (форсирование ходов во всех случаях, когда вы хотите избежать копирования вообще)? Если да, то какие шаблоны я должен ожидать, что компилятор будет следовать (или, скорее всего, следовать), что приведет к оптимизации и автоматическому перемещению здесь?

EDIT

Я хочу добавить, что я понимаю, как автоматические движения происходят на возвращении значения функции, поскольку применяется NRVO/РВО. Конкретный пример, который я привел здесь, не будет применяться RVO, поэтому я не уверен.

Answer 1

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

Вкратце: Нет, использование «трюка», такого как std :: move в способе, описанном в вопросе, не является преждевременной оптимизацией. Не использовать std::move, когда он может быть использован, тоже хорошо, если только код уже не известен как критически важный.

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

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

Связанный пример: Люди, работающие с критическим кодом производительности, часто передают аргументы как ссылки на const (const std::string&). Поскольку это то, что они используют, они будут использовать один и тот же шаблон в коде, который не является критичным для производительности, хотя они могут просто использовать pass-by-copy (const std::string или даже std::string). Это тоже не преждевременная оптимизация.

Answer 2

После std::move исходный объект, в данном случае var, должен находиться в допустимом состоянии, но может содержать любое значение, например. он может быть пустым.

Если вы знаете, что не собираетесь использовать var, и вы создали его только для того, чтобы положить его в vector, то это не действительно «преждевременная» оптимизация, как намерение того, что вы пытаетесь сделать.

vector имеет новый метод emplace_back(), который является тем же, но понятным, и использует форвардные аргументы (здесь вы просто делаете emplace_back("Hello World"), если все, что вы делаете, это его создание). В вашем случае, поскольку вы «вносите некоторые изменения с var», emplace_back вряд ли будет уместным.

В старой C++ вы можете оптимизировать копию, выполнив push_back() на пустой строке, а затем заменив ее.

Answer 3

Я не знаю, почему все предлагают использовать emplace_back(). Цель emplace_back() состоит в том, чтобы избежать операций копирования/перемещения, построив объект на месте. В этом случае вы уже создали объект, поэтому по крайней мере 1 копия/перемещение неизбежно. В этом случае нет преимущества использовать emplace_back() по сравнению с push_back().

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

Answer 4

Я не уверен, как компилятор будет оптимизировать копию (если вообще) без std::move().

Только очень умный компилятор может оптимизировать, что далеко, так что, если копия может быть дорого (например, очень длинная строка), то лучше, чтобы переместить его.

Без переезда код эффективно последовательности звонков:

strlen // count "Hello World" 
malloc // allocate memory for string var 
strcpy // copy data into var 
malloc // re-allocate vector 
free // deallocate old vector 
malloc // allocate new string 
strcpy // copy from var to new string 
free // destroy var 

С ходом он становится:

strlen // count "Hello World" 
malloc // allocate memory for string var 
strcpy // copy data into var 
malloc // re-allocate vector 
free // deallocate old vector 

В теории умный компилятор может сделать это преобразование автоматически, но для компилятор для просмотра всех уровней абстракции, введенных конструкторами и деструктором, и функций-членов vector довольно сложно, поэтому доказательство того, что код можно было бы преобразовать, чтобы удалить malloc и free сложно.

Answer 5

Да, это преждевременная оптимизация, если это преждевременная оптимизация.

Позвольте мне уточнить:
Преждевременная оптимизация определяется тем, оптимизируете ли вы часть кода, которую вы не знаете, критичной по производительности. То есть преждевременная оптимизация никогда не определяется методом оптимизации, она всегда определяется местом оптимизации и вашими знаниями о том, что вы делаете.

---

Теперь о целесообразности оптимизации использования std::move():

С std::move() вам избежать поднятия тяжестей строительства копии, как распределение памяти, открепление, копии построения содержат элементы, деконструкции содержали элементы и т.д. Это хороший. Но одна часть решает: строительство/уничтожение контейнерного объекта.

emplace_back() имеет силу полностью избежать строительства временного объекта. Итак, всякий раз, когда вы можете избежать временного объекта, используя emplace_back(), у вас есть небольшая победа.

Учитывая качество кода (читаемость/ремонтопригодность): std::move() имеет недостаток, оставляя вас непригодным для использования объектом, который может быть источником ошибок. Этого не происходит с emplace_back(). Поэтому, опять же, более очевидно, что предпочтительнее.

Конечно, emplace_back() не может использоваться во всех контекстах, позволяющих использовать std::move(). Таким образом, если они критичны по производительности, std::move() может быть путем. Существуют некоторые очень эффективные варианты использования для оптимизации с std::move(). Тем не менее, вы также можете узнать, что вы можете написать код таким образом, чтобы не требовать каких-либо конструкций copy/move/emplace. Никогда не переставайте искать оптимальное решение при оптимизации!

В конце концов, остается, что правильность оптимизации с помощью std::move() полностью зависит от контекста: хорошая оптимизация везде, где это хорошая оптимизация.