Виктор Калесников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.Do you like it? Share on social networks!
- Дмитрий
- May 7, 2024, 3:40 p.m.
C ++ - Test 004. Pointers, Arrays and Loops
- Result:60points,
- Rating points-1
d
- dsfs
- April 26, 2024, 10:56 a.m.
C ++ - Test 004. Pointers, Arrays and Loops
- Result:80points,
- Rating points4
Last comments
Qt Linux - Lesson 001. Autorun Qt application under Linux как сделать автозапуск для флэтпака, который не даёт создавать файлы в ~/.config - вот это вопрос ))
АК
Qt WinAPI - Lesson 007. Working with ICMP Ping in Qt Без строки #include <QRegularExpressionValidator> в заголовочном файле не работает валидатор.
Анатолий КононенкоFeb. 5, 2024, 7:50 a.m.
EVADec. 25, 2023, 4:30 p.m.
Boost - static linking in CMake project under Windows Сделал всё по-как у вас, но выдаёт ошибку [build] LINK : fatal error LNK1104: не удается открыть файл "libboost_locale-vc142-mt-gd-x64-1_74.lib" Хоть убей, не могу понять в чём дел…
Qt/C++ - Lesson 056. Connecting the Boost library in Qt for MinGW and MSVC compilers Для решения твой проблемы добавь в файл .pro строчку "LIBS += -lws2_32" она решит проблему , лично мне помогло.
Now discuss on the forum
добавить qlineseries в функции в функции: "GPlotter::addSeries(QString title, QVector &arr)" я вызываю метод setChart(...), я в конструктор передал адрес на QChartView элемент
BlinCTMay 5, 2024, 11:46 a.m.
Best Indian Food Restaurant In Cincinnati OH Ready to embark on a gastronomic journey like no other? Join us at App india restaurant and discover why we're renowned as the Best Indian Food Restaurant In Cincinnati OH . Whether y…
Evgenii LegotckoiMay 2, 2024, 8:07 p.m.
IscanderCheApril 30, 2024, 10:22 a.m.
к примеру уменя через сигнал/слот без проблем проходят большие данные, торможений не замечено, даже гонял кадры стрима с камер видеонаблюдения без задержек в виде "cv::Mat"
Дело не в торможениях.)
Это именно мое стремление к максимальной производительности.
А еще важный ньюанс что это будет большой обьем передаваемый маленькими пакетами с минимальными задержками.
Когда будут идти видеоданные с сотен источников каждый такт процессора будет иметь значение.
Сейчас у меня через сигнал слот реализовано.
Ищу оптимизации.
В дополнение к вашим трём вариантам можно упомянуть способ QMetaMethod::invoke (работает только на invokable методах). По сути он делает то же, что и первый. А вообще все три варианта предполагают использование очереди: в первом сигналы и слоты из разных потоков соединяются через очередь, во втором присутствует очередь событий, в третьем преполагается явное использование собственной. Задержки при передаче данных между потоками в любом случае будут, так как присутствует синхронизация (грубо говоря, мьютексы или что-то аналогичное). Логично предположить, что задержки будут тем меньше в сумме занимать времени, чем реже происходит передача данных, например при увеличении размера пакета. Возможно, есть ещё какие оптимизации (не выходящие за рамки использования Qt), но сходу придумать не получается.
Кстати, собственная очередь теоретически будет работать быстрее, так как будет отрабатывать только ваши задачи, в то время как очереди соединений сигналов-слотов и событий приложения глобальны для всего приложения (то есть там будет много "лишнего"). Но эффективную обработку писать уже придётся самостоятельно, само собой.
Да, соглашусь с вами что именно создание собственной очереди выглядит наиболее перспективной.
Сразу вижу что логично будет на ходу менять порты\потоки соединений источников для взаимодействия между собой в одном потоке.
Пример: Клиент А хочет переслать видеопоток клиенту Б.
Если прямое А-Б соединение невозможно из-за симметричного NAT то переподключить их в один серверный порт\поток.
Теоретически тогда можно не писать свой велосипед очереди событий.
Да кстати спасибо за подсказку что для уменьшения латентности между потоками лучше передавать сразу несколько пакетов данных объединённых в один.