Согласен с Lomir'ом на счет размера массива: он должен быть не слишком большим, чтобы не сказывалось обращение к свопу. Только в его варианте нужно вместо push_back обращаться к элементам по индексам. Тогда скорость работы вектора и массива будут совершенно одинаковыми (с учетом статистических погрешностей) - проверено на VS 2003.

И в конце концов, если мы гонимся за эффективностью и не хотим отказываться от удобств, предоставляемых вектором, кто мешает обращаться с ним, как с массивом? 

господа, ткните пальцем, где дополнительные механизмы!
точнее они есть, но если их не использовать (работать так же как и с массивом)

кеширование? шутишь? это же не жесткий диск...

вектор - тоже геморрой... но он уже готовый... точно также как и готовые в boost пулы... также, как и этот аллокатор, который можно сделать один раз и не парится

универсальность хотя бы... ну это каждому по вкусу...


щёлк

А что, в векторе нет контроля выхода за пределы индекса?

только в методе at(size_t)

есть, но не во всех методах, например в operator[] нет, а в at() есть.

Она не обязана  быть в []. Но МОЖЕТ присутствовать в отладочных версиях.

Вектор является ведь шаблонным классом.
И когда идет вызов переменной типа Vector - то передается как минимум 2 адреса: самого объекта и функции, которую необходимо вызвать. Соответственно - вот дополнительный сервис.

И вообще спор этот с моей точки зрения абсолютно бессмысленен.
Вектор ОБЯЗАН быть медленнее - только потому, что это высокоуровневый объект (класс). Со всеми вытекающими отсюда  накладными расходами - код дополнительных методов и т.п. 
Отсюда же следует, что вектор ОБЯЗАН быть удобнее - на то это и есть высокоуровневый объект.

Мне стало интересно - я слегка модернизировал приведенный тест - так, чтобы он всетак ближе был к реальности.
Я избрал такой вариант:


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

Я и так был в этом уверен на 99% (чудес на свете не бывает), но тут в обсуждении все по-разному говорили, вот я и решил сам посмотреть.
В среднем массив быстрее вектора примерно на 20% и это абсолютно нормально.


Это сообщение отредактировал(а) Anikmar - 22.4.2007, 18:24

Не стоит обобщать свой опыт на все компиляторы и все оптимизаторы.


Как мы видим, всё совсем не так однозначно.

Абсолютная неправда.

Добавлено через 1 минуту и 1 секунду

а inline?

я уже говорил выше, что IS принуждает компилятор ф-ции, определённые внутри класса далеть inline... соответственно ничего никуда не передаётся и нету нигде накладных расходов...

А что такие цифры огромные?

На самом деле я не обобщаю на все компиляторы, я взываю к здравому смыслу. 
Вектор написан на Си и использует абсолютно такую же технологию как и голый массив - это же шаблон! И где-то там внутри сидит оператор доступа к массиву - его можно посмотреть под отладчиком:

  const_reference operator[](size_type __n) const { return *(begin() + __n); }

Только чтобы получить значение по этому адресу - как минимум происходит вызов функции ( вонкретном случае оператора [])
И нельзя заставить вектор быть быстрее голого массива - он ведь призван сделать массив удобнее - так как является надстройкой над стандартным массивом.

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

Как у меня:
В режиме отладки вектор медленее массива в 2 раза
В режиме без оптимизации - медленнее примерно на 2%
В режиме с оптимизацией - примерно 20%
Можно для интереса запустить на всю ночь, но совершенно нет никакого интереса этим заниматься.

Просто бессмысленный спор - вот и все. Я на форуме обратил внимание, что многие очень болезнено реагируют на любые попытки критики STL (на себе в свое время изучил)
Я не критикую  STL - а просто объяаляю факт: вектор слегка медленнее, но удобнее. И спорить с этим просто бессмысленно - так как даже в некоторых описаниях STL это прямо говориться.

что такое "IS"? И как оно "принуждает"?

В любом учебнике по Си сказано, что inline функция увеличивает скорость, но в качестве накладных расходов - использует  дополнительную память. Поверьте, даром ничего не бывает - если где-то прибавилось (в данном случае удобства) - значит где-то убавится (в данном случае скорости и памяти). Не понимаю, зачем так болезненно это воспринимать?   

На этом, я пожалуй раскланяюсь - спор ни о чем. Пустое.

В этой фразе явно видно непонимание сути inline. Что такое "дополнительная память"?
Как раз случай с вектором, это прямое доказательство ложности данного высказывания.

Это сообщение отредактировал(а) Daevaorn - 22.4.2007, 18:57