Комментарии 14
Читается тяжело, если честно.
Смысл задачи я, вроде, уловил, но если ключевая цель статьи "сравнить", то почему так мало внимания уделено непосредственно сравнению?
Прогнав тест получаем результат
Какой тест? Что тестируем? Как тестируем? Что за "предварительное индексирование"?
Открыл ваш тест на GitHub и вижу там какие-то слушатели, вывод в консоль и прочее не относящееся к непосредственно сериализации. Вы что померить хотели? Почему JMH не использовали?
Спасибо за замечание, думал прикрутить какие-нибудь замеры, к примеру hugo. Про jmh не слышал и сейчас могу отнестись скептически, так как понял, что он ломает работу с JIT и с GC, что может исказить реальное представление о скорости работы программы, но на будущее спасибо, обязательно гляну.
Однако, хотел бы также отметить, что статья не направлена на замеры бечмарк производительности кода, а проводит только "сравнительный" анализ скорости алгоритмов. Так как все замеры для всех подходов проводились в одинаковых условиях и относительная скорость работы сохраняется во всех тестах, то можно с полной уверенностью утверждать, что вывод по тестам правильный, а именно то что один подход медленнее другого.
Открыл ваш тест на GitHub и вижу там какие-то слушатели, вывод в консоль и прочее не относящееся к непосредственно сериализации
Protobuf является движком сериализации, про него и пишем, что конкретнее вы хотели увидеть?
Про раскрытие темы, спасибо за замечание
Прикрутив "какие-нибудь замеры" вы получите какие-нибудь результаты. Что только потом с ними делать? Создатели JMH на бенчмарках собаку съели. https://www.oracle.com/technical-resources/articles/java/architect-benchmarking.html
что конкретнее вы хотели увидеть?
Я, в тестах которые замеряют скорость сериализации, хотел бы видеть только её. Во-первых, потому что другие операции могут занять достаточно много времени. Во-вторых, это усложняет тест. Как со стороны оценить что ваши тесты правильные?
Замеры рефлексии и сериализации отдельно уже проведены. Автор пожелал провести сравнительные замеры механизмов взаимодействия с jni библиотекой, что отображено в шапке статьи.
По бечмарку думаю можно докрутить отключение JIT оптимизации в тесте, а также оптимизацию в cmake проекте. Однако и без бечмарков и отключений оптимизаций можно делать правильные выводы в работе, если погрешности этой самой работы не ломают конечный вывод. Думаю можно дополнительно высчитывать мат. ожидание и дисперсию по результатом. Прикрутим все в работе.
теперь джун стал умнее
Спорное утверждение, честно говоря.
Да, в сети, ему равных нет.
Аккуратнее надо с такими громкими заявлениями, есть и другие быстрые транспорты. Например Aeron может обеспечить отправку и приём миллиона сообщений в секунду с задержкой не более 100 микросекунд. Сможете с gRPC повторить?
Не знаю почему автор сделал акцент именно на скорости. Все-таки gRPC это про контракты, собственно RPC, и широкую поддержку сообществом. В этом его преимущество.
Кстати, посмотрел семплы aeron, создалось впечатление что это больше про RUDP транспорт, чем законченный RPC.
Хм, а чем openapi+ rest + json в этом плане хуже?
Тут очевидно, данных в текстовый вариант дольше сериализовать, так как нужно пройти через этап парсинга текста в число к примеру.
Спасибо@sergey-gornostaevза замечание, да в действительно заявление получилось не к месту громким.
Дополнительно хотел бы уточнить, что целей выбрать законченный RPC фреймворк - не было, и также можно было бы рассмотреть и другие доступные движки сериализации
Почти всем )
REST как идеология для service-service взаимодействия не так удобна, как RPC
Работа с json медленнее, чем с protobuf
У подходов json-over-http основные плюсы в человекочитаемости сообщений, большой гибкости при версионировании, отсутствием кодогенерации и большим удобством библиотек. Но если требуется и производительность и удобство - то приходится искать какие-то сложные решения, так как и grpc и json не очень подходят (
честно говоря, учитывая реализацию гугловских библиотек для работы с proto и ее порнографические билдеры, о удобстве речь не идет.
Ну и отсутствие null доставляет боль или вовсе приводит к багам, если программист не знает/пропустил этот нюанс.
По скорости согласен. Но так ли это важно в большинстве случаев?
Человекочитаемость и есть уберфича)
Кодогенерация и вовсе глобальное зло.
Угу, потому я и говорю, что нормального протокола до сих пор нет. У протобафа и grpc плохо с реализациями, у json-over-http с производительностью. Какой-нибудь упрощенный bson с эффективной десериализацией поверх сокетов был бы нормальным решением, если бы был популярным и поддерживался всякими проксями и мешами, но увы.
Не знаю почему автор сделал акцент именно на скорости
Потому что он сделал занятный велосипед, прикрутив protobuf (как я понял, gRPC тут вообще не при чём) для обмена между java и C++, и нужно оценить его жизнеспособность: много ли на нём накладных расходов. Если много, то ну его нафиг, иначе пусть живёт.
Отлично. Узнал из этой статьи, что в C++ завезли null-coalescing operator, правда, только для GCC и Clang
const char* name1 = name ?: "";
Protobuf или Reflection в JNI