История изменений
Исправление bonta, (текущая версия) :
В QVector есть поддержка copy-on-write, поэтому при любом вызове неконстантного метода производится проверка, нужно ли чначала скопировать данные. Кроме того, беглый взгляд на дифф между ветками показывает, что QVector кое-где передает по значению, это значит что эти проверки могут привести и к реальному копированию
Вот такая причина может быть как выше написали, а я еще хочу добавить что:
stl контейнеры достаточно примитивны, а qt-шные, вероятно более богаты ф-лом, не смотрел реализацию qt контейнеров, но возможно там много что завязано на их QVariant, что само по себе может отнимать такты процессора, но зато конечно предоставлять классную гибкость и удобства.
Ну и вот за всякие удобства и более широкие возможности приходится платить, а stl контейнеры весьма просты.
Кстати если есть желание прям вообще скорсть выжать - в работаете с вектором - нужно итерироваться не через индексы и итераторы а через обычные указатели.
К сожалению сейчас не могу найти ссылку с описанием этого и там еще хорошая таблица сравнения скорости работы была, кроме этой ссылки (https://www.reddit.com/r/cpp/comments/692qhk/stditerators_vs_raw_pointers_per...) - но в этой ссылке не совсем то, но тоже про этот эффект.
Но правда конечно к чему таки оптимизации, ведь в общем на уровне интерфейса так сказать никто не гарантирует что даже в векторе следующий за этим элемент будет на следующем адресе (если вдруг будут использовать нестандартный аллокатор, то так вполне может быть) - так что это скорее на поиграться возможность ускорить, а в реальный проектах не стоит так делать.
Исправление bonta, :
В QVector есть поддержка copy-on-write, поэтому при любом вызове неконстантного метода производится проверка, нужно ли чначала скопировать данные. Кроме того, беглый взгляд на дифф между ветками показывает, что QVector кое-где передает по значению, это значит что эти проверки могут привести и к реальному копированию
Вот такая причина может быть как выше написали, а я еще хочу добавить что:
stl контейнеры достаточно примитивны, а qt-шные, вероятно более богаты ф-лом, не смотрел реализацию qt контейнеров, но возможно там много что завязано на их QVariant, что само по себе может отнимать такты процессора, но зато конечно предоставлять классную гибкость и удобства.
Ну и вот за всякие удобства и более широкие возможности приходится платить, а stl контейнеры весьма просты.
Кстати если есть желание прям вообще скорсть выжать - и работаете с вектором - нужно итерироваться не через индексы и итераторы а через обычные указатели.
К сожалению сейчас не могу найти ссылку с описанием этого и там еще хорошая таблица сравнения скорости работы была, кроме этой ссылки (https://www.reddit.com/r/cpp/comments/692qhk/stditerators_vs_raw_pointers_per...) - но в этой ссылке не совсем то, но тоже про этот эффект.
Но правда конечно к чему таки оптимизации, ведь в общем на уровне интерфейса так сказать никто не гарантирует что даже в векторе следующий за этим элемент будет на следующем адресе (если вдруг будут использовать нестандартный аллокатор, то так вполне может быть) - так что это скорее на поиграться возможность ускорить, а в реальный проектах не стоит так делать.
Исходная версия bonta, :
В QVector есть поддержка copy-on-write, поэтому при любом вызове неконстантного метода производится проверка, нужно ли чначала скопировать данные. Кроме того, беглый взгляд на дифф между ветками показывает, что QVector кое-где передает по значению, это значит что эти проверки могут привести и к реальному копированию
stl контейнеры достаточно примитивны, а qt-шные, вероятно более богаты ф-лом, не смотрел реализацию qt контейнеров, но возможно там много что завязано на их QVariant, что само по себе может отнимать такты процессора, но зато конечно предоставлять классную гибкость и удобства.
Ну и вот за всякие удобства и более широкие возможности приходится платить, а stl контейнеры весьма просты.
Кстати если есть желание прям вообще скорсть выжать - и работаете с вектором - нужно итерироваться не через индексы и итераторы а через обычные указатели.
К сожалению сейчас не могу найти ссылку с описанием этого и там еще хорошая таблица сравнения скорости работы была, кроме этой ссылки (https://www.reddit.com/r/cpp/comments/692qhk/stditerators_vs_raw_pointers_per...) - но в этой ссылке не совсем то, но тоже про этот эффект.
Но правда конечно к чему таки оптимизации, ведь в общем на уровне интерфейса так сказать никто не гарантирует что даже в векторе следующий за этим элемент будет на следующем адресе (если вдруг будут использовать нестандартный аллокатор, то так вполне может быть) - так что это скорее на поиграться возможность ускорить, а в реальный проектах не стоит так делать.