Проблема не в потоках, а в попытке выполнять IO задачу синхронно. Посмотрите в сторону какой нибудь библиотеки для реализации цикла событий, например libuv, чтобы было реализовано получение уведомления о данных на канале связи с устройством.
Так же вам стоит реализовать объединение запросов чтения: вместо чтения каждого регистра по одному - объединяйте их чтение в один большой запрос диапазона регистров, а потом уже разбирайте полученный диапазон по своим DataPoint
Какая то ужасно дилетантская статья. Скорее всего сгенерирована нейросетью по запросу состоящему из заголовка. 1) QScopedPointer<QLabel> label(new QLabel("Hello", parent)); Дабл фри здесь не будет, в деструкторе ребенек убирается себя из списка детей. Зачем здесь ScopedPointer тоже непонятно, можно просто создать объект на стэке, если он будет нужен лишь временно - результат будет тот же (так иногда делают с QMsgBox). Ногострел может быть если только в рамках этого скоупа умрет уже сам родитель. 2) Любой умный указатель в таком цикле создаст оверхед. Умный указатель в цикле просто не нужен, вы получаете невладеющий указатель на сырые байты изображения. Зачем тут вообще указатели если владеет данными сам QImage? 3)Хотя в новых версиях Qt иногда применяется QScopedPointer, использование std-аналогов там затруднено требованиями к бинарной совместимости (ABI). Все намешано в кучу, std умные указатели ничем не хуже кутэшных при создании Pimpl. Человек даже не читал выхлоп нейросети, которая написала полную чушь. Pimpl как раз позволяет избежать проблем ABI и неважно как он реализован, эта идиома используется не только в QT
И так продолжать можно почти по каждому пункту, статья - мусор
Если уж вы используете Pimpl для сокрытия имплементации жсона, то лучше попробуйте FastPimpl, подобно тому что есть в userver. А то аллокаций получается туча на каждое маленькое значение.
Также хотелось бы бенчмарки сравнительные, сами по себе цифры судить невозможно. Попробуйте развернуть на той же машине GRPC и какой нибудь REST HTTP JSON API с похожими тестовыми нагрузками по объему данных и сравните.
Стоит подумать над кастомизацией транспорта. Что если пользователь захочет переиспользовать какой то свой другой текстовый или бинарный канал? Самый тривиальный пример - общение с JS через Websocket`ы. А в случае каких то внутренних коммуникаций можно гонять вместо текста гораздо более эффективные ubjson/msgpack/cbor и т.д.
И возможно ли будет добавить подобное?
server.Method("add", [](int a, int b){
return a + b;
});
API библиотеки позволяет сформировать схему, которая преобразуется в выверенный сниппет JS, который после eval становится функцией валидации (что гораздо быстрее, чем руками проверять значения в JS на typeof и т.д.). В случае со схемой в БД вряд ли библиотека чем то поможет.
К тому же в случае такой библиотеки это безопасно, потому что источником кода для eval является сам код страницы. А вот с БД стоит быть аккуратным, чтобы не заэвалить что-то недоверенное.
EmmyLua это плагин для IDEA, причем здесь отладка? Он лишь умеет работать с MobDebug, который должен быть на стороне исполняющегося кода (причем IDE в данном случае будет сервером, к которому должно подключиться отлаживаемое приложение)
memcpy безопасен только если вы уверены, что ... выравнивание не нарушено
Неверно. memcpy, а также std::bitcast будет все равно на выравнивание. Если точно известно что выравнивание подходит, то можно использова assume_aligned, чтобы убрать возможный оверхед на невыровненное чтение
Сразу ниже пояснение, что это просто очень большой набор инструментов/пакетов для разработки. Мета в том смысле, что работает поверх основной операционки (в случае ROS1 - почти любой линукс)
Аккаунт заведен 6 дней назад и такую же копипасту еще и в ВК репосте статьи в мертвом паблике тут же скинули. https://vk.com/wall-193131136_84198
Проблема не в потоках, а в попытке выполнять IO задачу синхронно. Посмотрите в сторону какой нибудь библиотеки для реализации цикла событий, например libuv, чтобы было реализовано получение уведомления о данных на канале связи с устройством.
Так же вам стоит реализовать объединение запросов чтения: вместо чтения каждого регистра по одному - объединяйте их чтение в один большой запрос диапазона регистров, а потом уже разбирайте полученный диапазон по своим DataPoint
Чем то похожим я занимаюсь здесь:
https://github.com/cyanidle/radapter/blob/56a79ae0b76f1bc991a914cd7606f86e5135405b/src/workers/modbus/modbus_units.hpp#L121
Какая то ужасно дилетантская статья. Скорее всего сгенерирована нейросетью по запросу состоящему из заголовка.
1)
QScopedPointer<QLabel> label(newQLabel("Hello", parent));Дабл фри здесь не будет, в деструкторе ребенек убирается себя из списка детей. Зачем здесь ScopedPointer тоже непонятно, можно просто создать объект на стэке, если он будет нужен лишь временно - результат будет тот же (так иногда делают с QMsgBox). Ногострел может быть если только в рамках этого скоупа умрет уже сам родитель.
2)
Любой умный указатель в таком цикле создаст оверхед.Умный указатель в цикле просто не нужен, вы получаете невладеющий указатель на сырые байты изображения. Зачем тут вообще указатели если владеет данными сам QImage?
3)
Хотя в новых версиях Qt иногда применяется QScopedPointer, использование std-аналогов там затруднено требованиями к бинарной совместимости (ABI).Все намешано в кучу, std умные указатели ничем не хуже кутэшных при создании Pimpl. Человек даже не читал выхлоп нейросети, которая написала полную чушь. Pimpl как раз позволяет избежать проблем ABI и неважно как он реализован, эта идиома используется не только в QT
И так продолжать можно почти по каждому пункту, статья - мусор
Если уж вы используете Pimpl для сокрытия имплементации жсона, то лучше попробуйте FastPimpl, подобно тому что есть в userver. А то аллокаций получается туча на каждое маленькое значение.
Также хотелось бы бенчмарки сравнительные, сами по себе цифры судить невозможно. Попробуйте развернуть на той же машине GRPC и какой нибудь REST HTTP JSON API с похожими тестовыми нагрузками по объему данных и сравните.
Стоит подумать над кастомизацией транспорта. Что если пользователь захочет переиспользовать какой то свой другой текстовый или бинарный канал? Самый тривиальный пример - общение с JS через Websocket`ы. А в случае каких то внутренних коммуникаций можно гонять вместо текста гораздо более эффективные ubjson/msgpack/cbor и т.д.
И возможно ли будет добавить подобное?
Сам я тоже просто делал похожее
https://github.com/cyanidle/rpcxx
Во первых нет, не лучше. Во вторых претензии к разрабам QEMU, что те выбрали meson
Оригинальные скрипты сборки той версии QEMU как раз - meson.build в корне. Никто не удалял оригинальные скрипты сборки, зачем МЦСТ заниматься таким
API библиотеки позволяет сформировать схему, которая преобразуется в выверенный сниппет JS, который после
evalстановится функцией валидации (что гораздо быстрее, чем руками проверять значения в JS наtypeofи т.д.). В случае со схемой в БД вряд ли библиотека чем то поможет.К тому же в случае такой библиотеки это безопасно, потому что источником кода для
evalявляется сам код страницы. А вот с БД стоит быть аккуратным, чтобы не заэвалить что-то недоверенное.EmmyLua это плагин для IDEA, причем здесь отладка? Он лишь умеет работать с MobDebug, который должен быть на стороне исполняющегося кода (причем IDE в данном случае будет сервером, к которому должно подключиться отлаживаемое приложение)
Неверно. memcpy, а также std::bitcast будет все равно на выравнивание. Если точно известно что выравнивание подходит, то можно использова assume_aligned, чтобы убрать возможный оверхед на невыровненное чтение
Сразу ниже пояснение, что это просто очень большой набор инструментов/пакетов для разработки. Мета в том смысле, что работает поверх основной операционки (в случае ROS1 - почти любой линукс)
А почему не Lua собственно, я как увидел локал подумал, что это он и есть.