Скорость чистого перебора — как такое может быть?
В вопросе НЕТ НИКАКИХ СОБРАННЫХ ДАННЫХ, чтобы грамотно и чётко ответить на этот вопрос!
Ни собранных метрик, ни архитектуры, ни используемых технологий, ни тип приложения, ни инструменты компиляции кода, ни репозитория (или структуры), и т.д. - НИЧЕГО этого НЕТ.

Профилирование?! Нет, не слышали. :)
Ок. Сделайте вручную сами: возьмите и добавьте в инкапсулирующие (вызовы объектов) и итерационные вызовы (циклы, рекурсии) тайминги и ID-потоков (и другие метрики, для используемого функционального окружения).
После замера - сами всё увидите.

Профилирование перебора, очевидно, покажет, что все время жрет перебор, это я и так понимаю...Странно, что только Вы это понимаете! ;)

я постараюсь рассказать, в чем дело, когда (и если) докопаюсь до истины....И покажу, что вы все тут нихрена не знаете, а я - д'Артаньян и могу ДАЖЕ! сам ответить на своё жалкое подобие "вопроса"!

UPD:
Код просто делает из двух отсортированных векторов третий, содержащий исключительно совпадающие значения.тут
— Это просто, как блин, — сказал он. — Это тривиально. Это плоско и банально. Это даже неинтересно рассказывать
QtCreator при сборке Release-версии, оказывается, почему-то забывает сообщить своему qmake, что собирается именно Release-версия. 
Прописанное в проекте QMAKE_CXXFLAGS_RELEASE += -Ofast - просто игнорируется.
Достаточно заменить его на QMAKE_CXXFLAGS += -Ofast или добавить в вызов qmake CONFIG += release -  и собранная программа в Лине на реальном железе, разумеется, сразу кроет виртуальные Винды, как то положено природой.
Достаточно было внимательно заглянуть в вывод сборки, который, внезапно, от переключения между Debug и Release практически не менялся.
А дырочка
И щелочка
И странное отверстьице
Здесь вовсе ни при чем!