Приватные методы

[Racheengel]

Ну чтож, мы не знаем, правда это или нет. И если правда, разницу вы уж нам покажите своим примитивным тестом. Приведите примеры (учитывая особенность примимения вектора). Я вам лично не верю - с какой стати доверять кому либо?

Никому нельзя верить.

http://www.qtcentre.org/threads/36619-QVector-Slower-than-STL-Vector хоть и байан.
https://bugreports.qt.io/browse/QTBUG-44566 а тут даже с тестиком.

Запустил щас у себя в винде на старом интеле...
Результаты (Release, 32 бит, везде полная оптимизация):

Qt 5.2.1, MinGW:       QVector<int> 653 ms, std::vector<int> 225 ms
Qt 5.4.2, MSVC 2010: QVector<int> 468 ms, std::vector<int> 294 ms

QVector как бы тормоз в данном сценарии...  Может, у других не так, не знаю.
На рабочем проекте тоже были проблемы, в итоге мы повыкидывали почти все QVector из него.
Стало лучше.

[Racheengel]

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

Имеете в виду - все, кроме программирования?

[Авварон]

Пример из жизни, баг висит на qt багтрекере. std::vector значительно быстрей, чем QVector.

Слышал звон, да не знает где он. Лучше поглядите бенчмарки.

std::vector не "значительно" (в 3 раза, как написано в тикете) быстрее, а либо равен (с небольшим выигрышем std:: за счет отсутствия d_ptr), либо проигрывает в скорости (в случае Q_MOVABLE типов).

[Racheengel]

std::vector не "значительно" (в 3 раза, как написано в тикете) быстрее, а либо равен (с небольшим выигрышем std:: за счет отсутствия d_ptr), либо проигрывает в скорости (в случае Q_MOVABLE типов).

Смотрим бенчмарку... ось: linux_x86-64
Теперь смотрим тикет... ось: Windows 7 32 bit

Где там, какой звон?

[Авварон]

Ну да, на маргинальном случае вектор медленее, какой кошмар. Я вам даже скажу, какая строка тормозит:

Код:

if (!d->ref.isShared())

Так ли часто вы делаете takeLast в цикле?

Он бы еще operator[] замерил, тот тоже, я слышал, тормозной.

[Авварон]

Ну и если заменить вектор интов на вектор строк, то ВНЕЗАПНО эта проверка даёт нулевой оверхед.

[Igors]

Ну, опять свалились в примитивные тесты. Причем опять не дальше вектора И что хотите получить? Узнать "вот этот быстрее" и в дальнейшем юзать его (он ведь лучше). Это наивно.

На разницу в реализациях можно спокойно забить. Другое дело насколько контейнер хорош (или "адекватен") в конкретном случае. Но там думать надо. Напр у меня был случай когда по скорости удаления вектор оказался лучше чем std::map или др ассоциативный контейнер

[qate]

QVector как бы тормоз в данном сценарии...  Может, у других не так, не знаю.

да, в данном использовании он тормоз
но его могут исправить )
данный сценарий нереален - добавлять по одному int много раз сразу не оптимально
да и всеже разница невелика, не на порядок же )

[Авварон]

да, в данном использовании он тормоз
но его могут исправить )
данный сценарий нереален - добавлять по одному int много раз сразу не оптимально
да и всеже разница невелика, не на порядок же )

Вообще-то, append у std::vector и QVector одинаковый. В данном примере тормозит pop_back. В случае std::vector он занимает 0 (0 миллисекунд) - надо передвинуть 500000 указателей. В случае QVector он занимает 100 миллисекунд - надо передвинуть 500000 указателей и сделать 500000 проверок isShared().
Но никто в реальности не делает pop_back циклом, для этого есть QVector::erase(begin, end), к-ый делает 1 (одну) проверку isShared(). Автор теста - ССЗБ и не умеет пользоваться инструментом.

[AzazelloAV]

Вообще-то, append у std::vector и QVector одинаковый. В данном примере тормозит pop_back. В случае std::vector он занимает 0 (0 миллисекунд) - надо передвинуть 500000 указателей. В случае QVector он занимает 100 миллисекунд - надо передвинуть 500000 указателей и сделать 500000 проверок isShared().
Но никто в реальности не делает pop_back циклом, для этого есть QVector::erase(begin, end), к-ый делает 1 (одну) проверку isShared(). Автор теста - ССЗБ и не умеет пользоваться инструментом.

Тут главное сообщение в том, что вы указали на проблему - проверка isShared. Тогда все становится понятным и прозрачным. Но.... На то оно и но. Мы же используем std и его аналог. Зачем  менять тест? К чему я веду. STD - и Qt:STD  - это одно и тоже? Если нет, тогда вопросы отпали. Но ведь здесь хотят использовать однообразие, а не разные реализации стд, так что вопрос не закрыт. Это как использовать разный код с++ для разных компилеров, чтобы доказать, что какой-то лучше.

Если QList сравнивать с std, то там ещё мрачней по отличиям. Это такое. Но слушайте, объясните мне, для чего лист. Я вообще очень абстрактно понимаю, а точнее не понимаю. Я настолько часто вижу его использование, по сравнению с вектором, что реально не понимаю почему люди его туда суют. Возможно это связано с радость в энных годах, что он стал доступен, а не его ручками реализовывали, как раньше. Ну объясните мне! Очень хочу понять, искренне причем, где куча вставок важней быстроты доступа. И не подсказываете задачи про лист, которым вы не пользовались, я  сам вам могу примеров теоретических с вагон накатать.

[Авварон]

Если QList сравнивать с std, то там ещё мрачней по отличиям. Это такое. Но слушайте, объясните мне, для чего лист. Я вообще очень абстрактно понимаю, а точнее не понимаю. Я настолько часто вижу его использование, по сравнению с вектором, что реально не понимаю почему люди его туда суют. Возможно это связано с радость в энных годах, что он стал доступен, а не его ручками реализовывали, как раньше. Ну объясните мне! Очень хочу понять, искренне причем, где куча вставок важней быстроты доступа. И не подсказываете задачи про лист, которым вы не пользовались, я  сам вам могу примеров теоретических с вагон накатать.

Вы про linked list или QList?

[Igors]

Если QList сравнивать с std, то там ещё мрачней по отличиям. Это такое. Но слушайте, объясните мне, для чего лист. Я вообще очень абстрактно понимаю, а точнее не понимаю. Я настолько часто вижу его использование, по сравнению с вектором, что реально не понимаю почему люди его туда суют. Возможно это связано с радость в энных годах, что он стал доступен, а не его ручками реализовывали, как раньше. Ну объясните мне! Очень хочу понять, искренне причем, где куча вставок важней быстроты доступа. И не подсказываете задачи про лист, которым вы не пользовались, я  сам вам могу примеров теоретических с вагон накатать.

QList - основной контейнер Qt. Это как бы "гибрид"

1) Если sizeof(T) <= sizeof(void *) (т.е. размер эл-та не больше указателя на него), то QList работает как вектор. Плюс возможность prepend. Это оптимально не только для простых int но и для типов "формально указателей" напр QString

2) Иначе QList работает как вектор указателей, память выделяется под каждый эл-т (что довольно расходно). Но с более удобным синтаксисом, обращения как к вектору, нет забот по удалению (как с вектором указателей). Вставка/удаление в такой QList намного быстрее чем в вектор за счет того что двигаются/вставляются указатели (а не сами эл-ты). Хотя конечно "быстрой" ее не назовешь. Также ценная возможность - адреса эл-тов не "уплывают" как в векторе.

В общем - ничего гениального, но очень удобный, приятный контейнер. Немного сбивает с толку название - к "списку" он не имеет никакого отношения.

[Авварон]

В общем - ничего гениального, но очень удобный, приятный контейнер. Немного сбивает с толку название - к "списку" он не имеет никакого отношения.

Кстати, вот тут была бы в тему ваша присказка про букварь:) В букваре написано неправильно, дефолтным контейнером должен быть (Q)vector.
QList - устаревшее говно, к-ое проигрывает QVector'у по многим параметрам.
Основная беда в том, что "хороших" типов для QList не так много. Внезапно, QModelIndex - "плохой" тип (sizeof > sizeof(T*)), QImage - плохой тип (наследует PaintDevice и имеет vtable!), пользовательские типы - скорее всего плохие. То есть, в огромном количестве случаев QList будет фоллбечится в массив указателей, а значит а) жрать больше памяти б) делать туеву хучу аллокаций.

[Igors]

QList - устаревшее говно, к-ое проигрывает QVector'у по многим параметрам.
Основная беда в том, что "хороших" типов для QList не так много. Внезапно, QModelIndex - "плохой" тип (sizeof > sizeof(T*)), QImage - плохой тип (наследует PaintDevice и имеет vtable!), пользовательские типы - скорее всего плохие. То есть, в огромном количестве случаев QList будет фоллбечится в массив указателей, а значит а) жрать больше памяти б) делать туеву хучу аллокаций.

Я (визуально) помню из какой статьи почерпнуто это мнение. Не верьте Да, память жрется, но соображение "должен быть неперемещаемым" часто важнее (или необходимо), а QVector этого не обеспечивает.

[AzazelloAV]

Я (визуально) помню из какой статьи почерпнуто это мнение. Не верьте Да, память жрется, но соображение "должен быть неперемещаемым" часто важнее (или необходимо), а QVector этого не обеспечивает.

Можно подробней, про что вы, ничего не понял.

Независимо ни от чего, практически всегда (мы про глобальные вещи, правда?) индексные массивы используются для поиска по значению. Т.е. тупого перебора. И доступ по листу проигрывает жутко сильно вектору. Была бы задача  -  там поиск пользователь устроил, эка беда. Но вы возьмите Model-View Qt. Такой перебор он использует когда хочет, сколько хочет и как хочет и причем довольно часто.