Використовуючи масиви або std :: вектори в C ++, який розрив у продуктивності?

У нашому курсі C ++ вони пропонують більше не використовувати масиви C ++ для нових проектів. Наскільки я знаю, сам Stroustroup пропонує не використовувати масиви. Але чи є суттєві відмінності в роботі?

newСлід уникати використання масивів C ++ з (тобто використання динамічних масивів). Існує проблема, що вам слід відстежувати розмір, і вам потрібно видалити їх вручну та виконувати всілякі господарські роботи.

Використання масивів у стеці також не рекомендується, оскільки у вас немає перевірки діапазону, і передача масиву втратить будь-яку інформацію про його розмір (перетворення масиву в покажчик). Ви повинні використовувати boost::arrayв тому випадку, який обертає масив C ++ у малому класі та забезпечує sizeфункцію та ітератори для його перетворення .

Тепер std :: вектор проти рідних C ++ масивів (взяті з Інтернету):

// Comparison of assembly code generated for basic indexing, dereferencing, 
// and increment operations on vectors and arrays/pointers.

// Assembly code was generated by gcc 4.1.0 invoked with  g++ -O3 -S  on a 
// x86_64-suse-linux machine.

#include <vector>

struct S
{
  int padding;

  std::vector<int> v;
  int * p;
  std::vector<int>::iterator i;
};

int pointer_index (S & s) { return s.p[3]; }
  // movq    32(%rdi), %rax
  // movl    12(%rax), %eax
  // ret

int vector_index (S & s) { return s.v[3]; }
  // movq    8(%rdi), %rax
  // movl    12(%rax), %eax
  // ret

// Conclusion: Indexing a vector is the same damn thing as indexing a pointer.

int pointer_deref (S & s) { return *s.p; }
  // movq    32(%rdi), %rax
  // movl    (%rax), %eax
  // ret

int iterator_deref (S & s) { return *s.i; }
  // movq    40(%rdi), %rax
  // movl    (%rax), %eax
  // ret

// Conclusion: Dereferencing a vector iterator is the same damn thing 
// as dereferencing a pointer.

void pointer_increment (S & s) { ++s.p; }
  // addq    $4, 32(%rdi)
  // ret

void iterator_increment (S & s) { ++s.i; }
  // addq    $4, 40(%rdi)
  // ret

// Conclusion: Incrementing a vector iterator is the same damn thing as 
// incrementing a pointer.

Примітка. Якщо ви виділяєте масиви з newі не виділяєте некласові об'єкти (наприклад, звичайний int) або класи без визначеного користувачем конструктора, і ви не хочете, щоб ваші елементи були ініціалізовані спочатку, використання newвиділених масивів може мати переваги у виконанні, оскільки std::vectorініціалізує всі елементи до значення за замовчуванням (0, наприклад, для int) для побудови (зараховує до @bernie для нагадування).

Преамбула для мікрооптимізаторів

Пам'ятайте:

"Програмісти витрачають величезну кількість часу на роздуми або занепокоєння швидкості некритичних частин своїх програм. Ці спроби ефективності насправді мають сильний негативний вплив при розгляді налагодження та обслуговування. Ми повинні забути про невелику ефективність, скажімо про 97% часу: передчасна оптимізація - корінь усього зла. Але ми не повинні пропускати свої можливості на критичних 3% ".

(Завдяки метаморфозі за повну цитату)

Не використовуйте масив C замість вектора (чи будь-якого іншого) лише тому, що ви вважаєте, що це швидше, оскільки він повинен бути нижчого рівня. Ви помиляєтесь.

Використовуйте вектор за замовчуванням (або безпечний контейнер, адаптований до ваших потреб), а потім, якщо ваш профайлер каже, що це проблема, подивіться, чи можете ви їх оптимізувати, використовуючи кращий алгоритм або змінивши контейнер.

Це сказав, що ми можемо повернутися до початкового питання.

Статичний / динамічний масив?

Класи масивів C ++ краще поводяться, ніж низькорівневий масив C, оскільки вони багато що знають про себе, і відповідати на запитання масивів C не можуть. Вони здатні чистити після себе. І що ще важливіше, вони зазвичай записуються за допомогою шаблонів та / або вбудованих даних, а це означає, що те, що виявляється у великій кількості коду в налагодженні, дорівнює чи мало коду, що створюється у складанні випусків, що не означає різниці з їх вбудованою менш безпечною конкуренцією.

Загалом, він поділяється на дві категорії:

Динамічні масиви

Використання вказівника на масив malloc-ed / new-ed буде в кращому випадку таким же швидким, як версія std :: vector, і набагато менш безпечним (див. Пост лаб ).

Тому використовуйте std :: vector.

Статичні масиви

Використання статичного масиву буде в кращому випадку:

• так швидко , як станд :: масив версії
• і набагато менш безпечно.

Тому використовуйте масив std :: .

Неініціалізована пам'ять

Іноді, використовуючи vectorзамість сирого буфера, виникає видима вартість, оскільки vectorініціалізація буфера при створенні, тоді як код, який він замінює, ні, як зауважив Берні у своїй відповіді .

Якщо це так, то ви можете впоратися з цим, скориставшись unique_ptrзамість vectorабо, якщо випадок не є винятковим у вашій кодовій шкалі, насправді напишіть клас, buffer_ownerякий буде володіти цією пам'яттю, і забезпечить вам легкий і безпечний доступ до нього, в т.ч бонуси, такі як зміна розміру (використання realloc?) або все, що вам потрібно.

Вектори - це масиви під кришкою. Вистава однакова.

Одне місце, де можна зіткнутися з проблемою продуктивності, - це не розмір вектора правильно для початку.

По мірі заповнення вектора він змінює себе розмір, і це може означати, нове розподілення масиву з подальшими n конструкторами копій, а потім приблизно n n викликами деструктора з подальшим видаленням масиву.

Якщо ваша конструкція / руйнування дорога, вам набагато краще зробити вектор правильного розміру для початку.

Існує простий спосіб продемонструвати це. Створіть простий клас, який показує, коли він побудований / знищений / скопійований / призначений. Створіть вектор цих речей і почніть натискати на задній кінець вектора. Коли вектор заповниться, відбудеться каскад активності в міру зміни розміру вектора. Потім спробуйте ще раз з розміром вектора до очікуваної кількості елементів. Ви побачите різницю.

Щоб відповісти на щось, Мехрдад сказав:

Однак можуть бути випадки, коли вам все-таки потрібні масиви. Під час взаємодії з кодом низького рівня (тобто збіркою) або старими бібліотеками, які потребують масивів, можливо, ви не зможете використовувати вектори.

Не зовсім правда. Вектори чудово деградують у масиви / покажчики, якщо ви використовуєте:

vector<double> vector;
vector.push_back(42);

double *array = &(*vector.begin());

// pass the array to whatever low-level code you have

Це працює для всіх основних реалізацій STL. У наступному стандарті потрібно буде попрацювати (навіть якщо це сьогодні добре).

У вас є ще менше причин використовувати звичайні масиви в C ++ 11.

У природі є 3 види масивів від найшвидшого до найповільнішого, залежно від особливостей, які вони мають (звичайно, якість впровадження може зробити речі дуже швидкими навіть для випадку 3 у списку):

1. Статичний розмір, відомий під час компіляції. ---std::array<T, N>
2. Динамічний з розміром, відомий під час виконання та ніколи не змінювався. Типова оптимізація тут полягає в тому, що якщо масив можна виділити безпосередньо в стеку. - Недоступно . Можливо, dynarrayв C ++ TS після C ++ 14. В С є ЛОС
3. Динамічний та змінює розмір під час виконання. ---std::vector<T>

Для 1. звичайних статичних масивів із фіксованою кількістю елементів використовуйте std::array<T, N>в C ++ 11.

2. Для масивів фіксованого розміру, визначених під час виконання, але це не змінить їх розмір, є обговорення в C ++ 14, але він був переміщений до технічної специфікації та зроблений з C ++ 14 нарешті.

Для 3. std::vector<T> зазвичай просять пам’ять у купі . Це може мати наслідки для продуктивності, хоча ви можете використати std::vector<T, MyAlloc<T>>для покращення ситуації з користувацьким розподільником. Перевага порівняно з T mytype[] = new MyType[n];тим, що ви можете змінити його розмір і те, що він не розкладеться на покажчик, як це роблять звичайні масиви.

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

Ідіть зі STL. Немає покарання за виконання. Алгоритми дуже ефективні, і вони добре справляються з обробкою деталей, про які більшість із нас не думає.

STL - це сильно оптимізована бібліотека. Насправді навіть пропонується використовувати STL в іграх, де може знадобитися висока продуктивність. Масиви занадто схильні до помилок, щоб їх використовувати у щоденних завданнях. Сьогоднішні компілятори також дуже розумні і дійсно можуть створити відмінний код за допомогою STL. Якщо ви знаєте, чим займаєтесь, STL зазвичай може забезпечити необхідну продуктивність. Наприклад, ініціалізуючи вектори до потрібного розміру (якщо ви знаєте з самого початку), ви в основному можете досягти продуктивності масиву. Однак можуть бути випадки, коли вам все-таки потрібні масиви. Під час взаємодії з кодом низького рівня (тобто збіркою) або старими бібліотеками, які потребують масивів, можливо, ви не зможете використовувати вектори.

Про внесок дулі .

Висновок полягає в тому, що масиви цілих чисел швидші, ніж вектори цілих чисел (у моєму прикладі 5 разів). Однак масиви та вектори мають однакову швидкість для більш складних / не узгоджених даних.

Якщо ви компілюєте програмне забезпечення в режимі налагодження, багато компіляторів не вбудують в функцію аксесуара вектор. Це зробить реалізацію вектора stl набагато повільнішою в тих випадках, коли продуктивність є проблемою. Це також полегшить налагодження коду, оскільки ви зможете побачити у відладчику, скільки пам'яті було виділено.

В оптимізованому режимі я б очікував, що вектор stl наблизиться до ефективності масиву. Це тому, що багато векторних методів є вписаними.

Однозначно впливає на ефективність використання std::vectorпроти необробленого масиву, коли потрібно неініціалізований буфер (наприклад, використовувати як призначення для memcpy()). Anstd::vectorБуде форматувати всі його елементи , використовуючи конструктор за замовчуванням. Невисокий масив не буде.

Специфікація c ++ для std:vectorконструктора, який бере countаргумент (це третя форма), говорить:

`Конструює новий контейнер з різних джерел даних, необов'язково використовуючи аллокатор, що постачається користувачем.

3) Конструює контейнер з кількістю вставлених за замовчуванням екземплярів T. Копій не робиться.

Складність

2-3) Лінійна в рахунку

Невисокий масив не несе цієї вартості ініціалізації.

Дивіться також Як я можу уникати std :: vector <> ініціалізувати всі його елементи?

Різниця продуктивності між двома дуже залежить від реалізації - якщо порівнювати неправильно реалізований std :: вектор з оптимальною реалізацією масиву, масив виграє, але переверне його і вектор виграє ...

Поки ви порівнюєте яблука з яблуками (або масив, і вектор мають фіксовану кількість елементів, або обидва динамічно змінюються), я б подумав, що різниця в продуктивності незначна до тих пір, поки ви слідуєте за отриманням практики кодування STL. Не забувайте, що використання стандартних контейнерів C ++ також дозволяє використовувати попередньо прокатані алгоритми, що входять до стандартної бібліотеки C ++, і більшість з них, ймовірно, будуть більш ефективними, ніж середня реалізація того ж алгоритму, який ви створили самостійно .

При цьому вектор IMHO перемагає в сценарії налагодження з налагодженням STL, оскільки більшість реалізацій STL з належним режимом налагодження може принаймні виділити / спробувати типові помилки, які роблять люди під час роботи зі стандартними контейнерами.

О, і не забувайте, що масив і вектор мають однаковий макет пам'яті, тому ви можете використовувати вектори для передачі даних до застарілого коду С або С ++, який очікує базових масивів. Майте на увазі, що більшість ставок вимкнено в цьому сценарії, і ви знову маєте справу з необробленою пам'яттю.

Якщо вам не потрібно динамічно регулювати розмір, у вас є обсяг пам'яті для збереження ємності (один вказівник / size_t). Це воно.

Можливо, існує певний крайній випадок, коли у вас є векторний доступ до вбудованої функції всередині вбудованої функції, коли ви вийшли за рамки того, що компілятор буде вбудований, і це змусить виклик функції. Це було б настільки рідко, що не варто турбуватися - загалом я погодився б з litb .

Я здивований, що ніхто ще не згадав про це - не хвилюйтеся про ефективність, поки це не буде доведено, що це проблема, а потім орієнтир.

Я б заперечив, що головна проблема - це не працездатність, а безпека. Ви можете зробити багато помилок з масивами (розгляньте розмір розміру, наприклад), де вектор врятував би вам біль.

Вектори використовують трохи більше пам'яті, ніж масиви, оскільки вони містять розмір масиву. Вони також збільшують розмір програм на жорсткому диску і, можливо, слід пам'яті програм. Ці збільшення невеликі, але можуть мати значення, якщо ви працюєте із вбудованою системою. Хоча більшість місць, де ці відмінності мають значення, - це місця, де ви б використовували C, а не C ++.

Наступний простий тест:

Масив C ++ проти пояснення тесту на векторну ефективність

суперечить висновкам з "Порівняння коду складання, сформованого для базових операцій індексації, перенаправлення та збільшення кроків на векторах та масивах / покажчиках".

Повинна бути різниця між масивами та векторами. Тест говорить так ... просто спробуйте, код є ...

Іноді масиви дійсно кращі, ніж вектори. Якщо ви завжди маніпулюєте набором об'єктів фіксованої довжини, масиви краще. Розглянемо такі фрагменти коду:

int main() {
int v[3];
v[0]=1; v[1]=2;v[2]=3;
int sum;
int starttime=time(NULL);
cout << starttime << endl;
for (int i=0;i<50000;i++)
for (int j=0;j<10000;j++) {
X x(v);
sum+=x.first();
}
int endtime=time(NULL);
cout << endtime << endl;
cout << endtime - starttime << endl;

}

де векторна версія X

class X {
vector<int> vec;
public:
X(const vector<int>& v) {vec = v;}
int first() { return vec[0];}
};

і версія масиву X є:

class X {
int f[3];

public:
X(int a[]) {f[0]=a[0]; f[1]=a[1];f[2]=a[2];}
int first() { return f[0];}
};

Версія масиву буде main () буде швидшою, оскільки ми уникаємо накладних витрат "нового" кожного разу у внутрішньому циклі.

(Цей код був розміщений мною на comp.lang.c ++).

Якщо ви використовуєте вектори для представлення багатовимірної поведінки, є ефективність.

Чи 2d + вектори спричиняють показник ефективності?

Суть полягає в тому, що є невелика кількість накладних витрат з кожним підвектором, що містить інформацію про розмір, і не обов’язково буде серіалізація даних (як це відбувається з багатовимірними масивами c). Ця відсутність серіалізації може запропонувати більше, ніж можливості мікрооптимізації. Якщо ви робите багатовимірні масиви, можливо, найкраще просто розширити std :: vector і прокатати власну функцію get / set / resize бітів.

Якщо припустити масив фіксованої довжини (наприклад, int* v = new int[1000];порівняно std::vector<int> v(1000);з розміром, vякий фіксується 1000), єдине врахування продуктивності, яке дійсно має значення (або принаймні важливе для мене, коли я опинився в подібній дилемі) - це швидкість доступу до елемент. Я шукав векторний код STL, і ось що я знайшов:

const_reference
operator[](size_type __n) const
{ return *(this->_M_impl._M_start + __n); }

Цю функцію, безумовно, підкреслить компілятор. Отже, поки єдине, що ви плануєте зробити, vце отримати доступ до його елементів operator[], здається, що насправді не повинно бути різниці в продуктивності.