LINUX.ORG.RU
Новости — Разработка  

QtProtobuf 0.5.0

 , , , ,


0

2

Выпущена новая версия библиотеки QtProtobuf.

QtProtobuf — свободная библиотека, выпускаемая под лицензией MIT. С ее помощью вы можете с легкостью использовать Google Protocol Buffers и gRPC в вашем Qt проекте.

Ключевые изменения:

  • Добавлена библиотека поддержки Qt-типов. Теперь можно использовать часть Qt типов в описании protobuf сообщений.
  • Добавлена поддержка Conan, спасибо @GamePad64 за помощь!
  • Вызов методов call и subscription в QtGrpc теперь потокобезопасны.
  • Добавлено поле returnValue для QQuickGrpcSubscription. Теперь можно делать QML биндинг на сообщения созданные в QML контексте без промежуточных обработчиков.
  • Для согласования с концепциями protobuf, все поля в сообщениях выставляются в значения по умолчанию перед началом десериализации.

Незначительные изменения:

  • Переработан поиск qmake в процедуре простройки проекта. Приоритет отдается qmake из CMAKE_PREFIX_PATH.
  • Переработана статическая простройка проекта, исправлены некоторые ошибки.
  • Исправлена ошибка «зависшей» подписки при работе с QQuickGrpcSubscription и QML контекста.
  • Добавлена конвертация для типа google.protobuf.Timestamp из/в QDateTime.

>>> Подробности



Проверено: leave ()
Последнее исправление: leave (всего исправлений: 3)

Ответ на: комментарий от upcFrost

А, так там же написано - presence tracking. Сначала сделали самый простой вариант - или значение или дефолтное значений (условный «ноль»). Теперь расширили до того чтобы давать дополнительный сигнал, было ли значение вообще установлено.

Это уж получше чем в proto2 где нужно было всегда засорять определение словом optional

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Сначала сделали самый простой вариант - или значение или дефолтное значений (условный «ноль»). Теперь расширили до того чтобы давать дополнительный сигнал, было ли значение вообще установлено.

Я ж и говорю - проектирование уровня «бог». Сразу дойти что presence надо отслеживать видимо не смогли, хотя даже в xml давно различают nil и null

upcFrost ★★★★★
()
Ответ на: комментарий от incker

Protocol buffers - годнота

Говнота. Оно уже перестало дико тормозить на больших сообщениях и делать миллиарды выделений памяти?

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

Вот да.

Довелось тут сравнивать для продакшена thrift/tcp/binaryprotocol vs grpc/protobuf/http2.
C#/Win - client. C++/Lin - server.

Dataset - список из структур 12 байт каждая. Размер 1000 и 100000 штук в массивеm т.е. 11KB и ~1MB соответсвенно.

На C# у обоих какя-то жопа, вместо производительности:

grpc/http2 на 100k за раз задыхается, медиана ~600ms, MaxReceiveMessageLength задран до INT_MAX.

Ну а thrift на 100k вообще живет за гранью добра и зла.

Такое ощущение, что вся эта шляпа нужна только для того, чтобы передать адрес сокета и размер payload’a, который буду руками отдавать.

anonymous
()
Ответ на: комментарий от anonymous

Заглянули в ванильную stdnet реализацию Thrift, потом в picap под в Wireshark’ом:

Там на каждую сериализуемую структуру дергается своя запись в сокет.

Итого на шмат из 10000 сообщений превращается в 26000 пакетов (10K data + 16K control) по 50-60 байт. Сериализатор - говно.

На C++ такого нет. Там кладут пачку в буфер и присовывают в сокет,
и как следствие имеют ~50ms на 1MB.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Разработка