От «быстрого JSON» к потоковой обработке данных: смена парадигмы в оценке производительности протоколов

[achekalin]

т.е., кратко,

• не декодируйте JSON больше, чем требуется задаче.

• если вам нужны только границы объектов — ищите границы; если несколько полей — извлекайте их.

• если данные приходят потоком — обрабатывайте их потоком.

• измеряйте latency до полезного результата, а не только полное время разбора»

Вроде так. А уж вопрос реализации - это, получается, именно вопрос именно конкретики. И языка реализации конкретики.

[ihar76]

Всё абсолютно верно, вы очень точно сформулировали суть! Идея как раз в том, чтобы сместить фокус с „давайте разберем всё и как можно быстрее“ на „давайте сделаем ровно столько работы, сколько нужно для конкретного шага в потоке“. Спасибо за отличные выводы!
Честно, я точнее не сформулировал бы. Конечно, есть технические нюансы, но тем не менее.

[OlegZH]

А как же традиционные потоки ввода/вывода? Посылаем пакетами, получаем пакетами. В пакетах — отдельные отсчёты временных рядов.

[ihar76]

не совсем понятен вопрос. речь про сетевые протоколы или про передачу данных?

[noldo32]

Зачем вообще JSON. Раньше процедуры вызывали, передавая им бинарные данные. Есть ведь gRPC - вместо передачи понятных человеку строк (вроде {"userId": 15, "userName": "Alex"}), Protobuf превращает эти данные в компактный и оптимизированный поток байтов. И процедуры вызываются как в старые добрые времена.

[ihar76]

gRPC -- отличный протокол передачи данных. Но он подходит далеко не для всех сценариев работы. Тут статья не про достоинства JSON а про то, как сделать его реально быстрым, простым и удобным