производительность передачи данных между потоками

Рекомендуємо хостинг TIMEWEB

Стабільний хостинг, на якому розміщується соціальна мережа EVILEG. Для проектів на Django радимо VDS хостинг.

к примеру уменя через сигнал/слот без проблем проходят большие данные, торможений не замечено, даже гонял кадры стрима с камер видеонаблюдения без задержек в виде "cv::Mat"

Дело не в торможениях.)
Это именно мое стремление к максимальной производительности.
А еще важный ньюанс что это будет большой обьем передаваемый маленькими пакетами с минимальными задержками.
Когда будут идти видеоданные с сотен источников каждый такт процессора будет иметь значение.
Сейчас у меня через сигнал слот реализовано.
Ищу оптимизации.

В дополнение к вашим трём вариантам можно упомянуть способ QMetaMethod::invoke (работает только на invokable методах). По сути он делает то же, что и первый. А вообще все три варианта предполагают использование очереди: в первом сигналы и слоты из разных потоков соединяются через очередь, во втором присутствует очередь событий, в третьем преполагается явное использование собственной. Задержки при передаче данных между потоками в любом случае будут, так как присутствует синхронизация (грубо говоря, мьютексы или что-то аналогичное). Логично предположить, что задержки будут тем меньше в сумме занимать времени, чем реже происходит передача данных, например при увеличении размера пакета. Возможно, есть ещё какие оптимизации (не выходящие за рамки использования Qt), но сходу придумать не получается.
Кстати, собственная очередь теоретически будет работать быстрее, так как будет отрабатывать только ваши задачи, в то время как очереди соединений сигналов-слотов и событий приложения глобальны для всего приложения (то есть там будет много "лишнего"). Но эффективную обработку писать уже придётся самостоятельно, само собой.

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

Сразу вижу что логично будет на ходу менять порты\потоки соединений источников для взаимодействия между собой в одном потоке.
Пример: Клиент А хочет переслать видеопоток клиенту Б.
Если прямое А-Б соединение невозможно из-за симметричного NAT то переподключить их в один серверный порт\поток.
Теоретически тогда можно не писать свой велосипед очереди событий.

Да кстати спасибо за подсказку что для уменьшения латентности между потоками лучше передавать сразу несколько пакетов данных объединённых в один.