разница получается из-за того что при

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

Даже при
 
у меня натикало 11968, а вариант с динамическим выделением - всего 890   

g++-3.4.2+stlport-5.1.3 в релизе(про дебаг отдельно) даёт 234 против 343 (vector и new соответственно)...  
насчёт дебага: прелесть контейнеров в том, что, в дебаг-режиме они проверяют всё на логические ошибки... к примеру, если после изменения контейнера использовать итератор, полученный до этого изменения, то он(итератор) кинет исключение(smart-iterator), в релизе же даже не пикнет(fast-iterator)...

насчёт менеджера памяти: изначальный вариант я не поленился запустить 25 раз (только new, vector даже пробовать не стал)... каждый раз результат был всё меньше и меньше, причём, разрыв между первым запуском и последним был чуть ли не в 10 раз... короче говоря результат сильно зависит и от менеджера памяти и от операционной системы и от объёма оперативной памяти...

Ничего там не тратится, это же не конструктор копирования.

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

НЕ ВЕРНО. 
Запись vector<int> (50000) создает вектор из 50000 ПРОИНИЦИАЛИЗИРОВАННЫХ элементов.



Это сообщение отредактировал(а) Mayk - 21.4.2007, 19:31

кстати, ещё одна "мелочь": вектор имеет инициализированные значения (0)... отсюда и разница такая... а вот как объяснить, что в цикле записи вектор работает быстрее чем дин-массив я затрудняюсь... но говорит это только в его пользу 

Добавлено через 40 секунд
Mayk, опередил 

nickless - за второе замечание спасибо
а по поводу 

готов спорить....
to Mayk -   



Это сообщение отредактировал(а) boriska - 21.4.2007, 19:38

Я вообще имел ввиду 
и

Какой именно временный объект там создаётся? int?

То что вектор инициализирует память, с этим я не спорю.

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

Vector нужен, когда количество элементов заранее не известно. Точка.


Увеличение скорости даже на 10% иногда очень важно. А уж в данному случае, когда прирост 50-100%...


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


вот... иногда инициализация такая не нужна.


Ну а тут и ты не прав... Кто же в дебаге скорость проверяет? Инлайнинг функций-то в дебаге не производится... как минимум. А, уже сказали до меня по этому поводу...
А вообще по ходу поддерживаю. Если размер заранее известен, то даже 50% прирост скорости весьма существенен. Векторное - векторному.
В данном случае использовать вектор ради всего лишь автоматического удаления... имхо, не то.

50000000 Это слишком большое число для масивов, т.к. время работы зависит от свободной памяти, распределение страниц, виртуальной памяти и т.д.
У меня на VS 2005 1 раз вектор работал 2сек, 2 раз около 1,5 все последущие 0,7 сек.
Масив 0,5 сек.
Привиду свой тест:

Вектор: 1,7сек
Масив: 1,5сек

Вектор немного отстает, но если им правильно пользоваться то отставание не большое - максимум процентов 20-35.
ИМХО во всех программах особо не чуствительных к скорости лучши пользоваться вектором. Кроме того вектор непожирает лишнюю память, и не инициализирует обьекты пока они не нужны.
Например зачем нам иметь масив из 100000 обьектов (причем все будут инициализированы), если мы пользуем в 80% тока 100.

Это сообщение отредактировал(а) Lomir - 21.4.2007, 23:46

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

Намного быстрее объявить 1000000 элементов сразу без инициализация, чем потом 20 раз перераспределять и/или выделять поблоково эти данные.

Массив динамический вообще не инициализирует память...


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

Lomir, ты не понял... push_back мы не используем... мы ставим и вектор и new в равные условия - заранее сообщаем длину массива и используем оператор [] для доступа к эдементам...

ммм... про прирост памяти ты умолчал...

насчёт "его проблемы" - если я не ошибаюсь, то эта "проблема" решается путём смены аллокатора (второй шаблонный параметр вектора...)

угу, а то, что при доступе к объектам скорость +30% (хотя, я это объяснить не могу) тебя не смущает...


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


из-за 4-40 байт ты готов пожертвовать всеми этими прелестями?

а, что, если от неё можно избавится? ;)


ну и в заключении: кто-нибудь может объяснить то, что доступ к элементам для вектора быстрее, чем для массива созданного с помощью new?

Достаточно прикольный спор получился.
Мне кажется что-то не так - ведь вектор изнутри организован стандартными функциями.

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

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

ИМХО:
Для большинства задач вектор подходит идеально, но как любая универсальная штуковина она просто ОБЯЗАНА съедать больше ресурсов - за удобство надо платить. 
В задачах, где рессурсы критичны, собственное хранилище данных несомненно будет более экономичное. Любой мастер своего дела (в любой специальности) имеет как наборы стандартных инструментов, так и собственные приспособления, с помощью которых он достигает лучшего результата. Так и в программировании. Так что правы все стороны.   

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



Геморрой, имхо. В массиве ничего дополнительно делать не надо.



Какими? Автоматическое удаление? В данном случае - выделки не стоит.


выложи полный код еще раз (если он изменился), на котором ты получил +30%. А я у себя проверю... что получится.

тьфу..описался я не памяти ,а скорости