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

Question

Виктор КалесниковFeb. 7, 2022, 7:29 a.m.

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

Делаю вторую версию многопоточного сервера на Qt.
И есть актуальный вопрос о том "как быстрее" в пересылке небольших пакетов по 500 байт между потоками???
(условно 8 потоков обмениваются пакетеми данных из UDP сокетов (Dtls))

1) Удобно конечно сигнал/слот. Но это относительно медленно.
2) Послать событие в нужный поток. postEvent() Это быстрей чем сигнал/слот? Или то же самое?
3) Велосипед из очереди событий. CallBack?

Понятно что есть boost asio но хочется чистый Qt.

Буду премного благодарен за полезную информацию или рекомендации.

We recommend hosting TIMEWEB

Stable hosting, on which the social network EVILEG is located. For projects on Django we recommend VDS hosting.

Subscribe to the discussion3

Section subscription248

Do you like it? Share on social networks!

Feb. 7, 2022, 8:14 a.m.

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

Feb. 7, 2022, 8:25 a.m.
(edited)

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

Feb. 7, 2022, 12:09 p.m.

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

Feb. 7, 2022, 12:35 p.m.

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

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

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

Comments

Only authorized users can post comments.
Please, Log in or Sign up