У меня размер вектора 24 байта. Размер дека 80. Я не говорю, что вермя мува пропорционально размеру объекта, но дек заметно сложнее вектора.

Хотя и мув и своп в деке просто копируют все поля. Так что выходит, что действительно пропорционален объему.

Но чтобы сделать хоть сколь-нибудь обоснованный вывод, нужно профилировать и смотреть что именно делает код. Кроме того, то что иногда код без мува оказывается заметно медленее наводит на мысли, что в самом бенче есть проблемы. По-моему на cppcon был интересный доклад посвященный эффектам влияющим на результаты микробенчмарков.

Проблемы называются оптимизация процессора, о чем я выше и написал

И как оптимизации могли сделать код работющий с неподвижным объектом быстрее мувов?

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

В смысле наоборот. Код с мувами быстрее неподвижного объекта.

я понял, да

У тебя в коде миллионы деков, что их мув роляет?

Нет, один. Но мувается на каждом шаге цикла. Ссылку на код можно найти по цепочке реплаев.

У меня есть подозрение, что это задача не уровня pro.cxx чатика, тебе нужно в @supapro.cxx

Валидно ли в llvm собирать отдельные TU с одними санитайзерами (address,fuzzer), а другие TU с другими санитайзерами (address, fuzzer,undefined)?

Напоминаю, что картинки здесь запрещены

Почему бы их не отключить в настройках группы?

/report

почему меня выкинуло?

Всякое бывает :)

Фигня случается

Кажется надо как-то умудриться указать и компилятору разные санитайзеры и линкеру все:

Simply compile and link your program with -fsanitize=address flag. The AddressSanitizer run-time library should be linked to the final executable, so make sure to use clang (not ld) for the final link step. When linking shared libraries, the AddressSanitizer run-time is not linked, so -Wl,-z,defs may cause link errors (don’t use it with AddressSanitizer).

парни, если у меня в анонимном неймспейсе есть метод, который нужно покрыть юниттестами, какой правильный подход выбрать, чтоб до него добраться?