Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: scf  
Дата: 29.11.22 12:23
Оценка: +1
Здравствуйте, Codealot, Вы писали:

C>BSON, бинарный формат — по идее должен быть компактее и быстрее.


Компактный формат, быстрый формат и формат с поддержкой обратной/прямой совместимости данных — это, как правило, три разных формата.
Re: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: karbofos42 Россия  
Дата: 29.11.22 12:43
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Как, вот как можно было всё настолько изгадить?


Так частный случай же. Я как-то сравнивал на своих реальных объектах JSON и BSON (благо там пару строк кода всего поменять нужно).
BSON был и быстрее и компактнее, чем JSON (обе реализации были от Newtonsoft).
Правда у нас в итоге победил json, упакованный в zip
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rollcoin  
Дата: 29.11.22 13:05
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

BFE>[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000...000000000000000000000000000000000000000000]

Re[2]: JSON vs BSON: очередное торжество больного воображения и
От: Mihas  
Дата: 29.11.22 13:13
Оценка:
Здравствуйте, swame, Вы писали:

S> Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам

S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
Прикольно
Работая с электронным документооборотом в бюджетной сфере, я насмотрелся всяких текстовых структурированных форматов. Запомню и этот в своей копилке возможного
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:19
Оценка:
Здравствуйте, rollcoin, Вы писали:

BFE>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

BFE>>[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000...000000000000000000000000000000000000000000]
R>Image: aekPFxJ0eeE.jpg

Забавно. Где-то потеряли 383. Это нормально?
И каждый день — без права на ошибку...
Re[7]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rollcoin  
Дата: 29.11.22 14:22
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Забавно. Где-то потеряли 383. Это нормально?


Кого потеряли? Какое 383?
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:26
Оценка:
Здравствуйте, Константин Б., Вы писали:

BFE>>Размер представления — это ещё не всё. К тому же, когда размер представления зависит от данных, то могут быть сюрпризы при изменении данных.

КБ>Какие сюрпризы?
Разные. Буфера не хватит, канал забьётся...

BFE>>А в накладные расходы входит сложность и корректность парсинга.

КБ>JSON.parse(x) — для меня достаточно просто.
И что там с корректностью?

КБ>А теперь вопрос: зачем мне предьявлять к парсеру такие требования? Что плохого случится если парсер сможет распарсить "[NaN]" например? По спеке вроде как нельзя. Повод ли это отказываться от парсера?

Несоблюдение спецификации ведёт к невозможности использования сторонних клиентов, например.

BFE>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

BFE>>[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000]
КБ>Ошибку конечно же.
Ошибку или ошибочный результат
Автор: rollcoin
Дата: 29.11.22
?
И каждый день — без права на ошибку...
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:30
Оценка:
Здравствуйте, rollcoin, Вы писали:

BFE>>Забавно. Где-то потеряли 383. Это нормально?

R>Кого потеряли? Какое 383?

Передали: 18446744073709551617.0
Получили: 18446744073709552000
Разница : +383
И да: не потеряли, а приобрели.
И каждый день — без права на ошибку...
Re[9]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: rollcoin  
Дата: 29.11.22 14:32
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, rollcoin, Вы писали:


BFE>>>Забавно. Где-то потеряли 383. Это нормально?

R>>Кого потеряли? Какое 383?

BFE>Передали: 18446744073709551617.0

BFE>Получили: 18446744073709552000
BFE>Разница : +383
BFE>И да: не потеряли, а приобрели.


Все согласно IEEE754
В JavaScript Object Notation все числа — это 53-битные флоаты.
https://www.rfc-editor.org/rfc/rfc7159#section-6
Re[8]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Dair Россия  
Дата: 29.11.22 14:35
Оценка:
Здравствуйте, rollcoin, Вы писали:

R>Кого потеряли? Какое 383?


Третье число увеличилось.

Это потому что оно, поди, в double хранится, и не хватило мантиссы, поэтому округлилось ...1617 до ...2000.
Re[10]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:42
Оценка: :)
Здравствуйте, rollcoin, Вы писали:

R>Все согласно IEEE754

R>В JavaScript Object Notation все числа — это 53-битные флоаты.
R>https://www.rfc-editor.org/rfc/rfc7159#section-6

Ну, т.е. это нормально — никакой надёжности, зато просто.
И каждый день — без права на ошибку...
Re[9]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 29.11.22 14:54
Оценка: +1
Здравствуйте, Dair, Вы писали:

D>Это потому что оно, поди, в double хранится, и не хватило мантиссы, поэтому округлилось ...1617 до ...2000.


Ну разумеется.
В результате нормальные программы передают в Json только строки. И числа передают строками, а уж потом сами парсят строки в числа.
Потому как формат дебильный.
Чего стоит одно то, что число 1. является некорректной записью!
И каждый день — без права на ошибку...
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 29.11.22 17:43
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Есть большое сравнение по перформансу с этими форматам/либами. Погугли. Под рукой нет ссылки.


Иди туда не знаю куда, ищи то не знаю что? Имей хоть какое-то уважение к чужому времени.

P>Подозреваю, в твоем случае либа BSON сильно корявая.


Newtonsoft.Json.Bson
Ад пуст, все бесы здесь.
Re[2]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 29.11.22 17:43
Оценка:
Здравствуйте, karbofos42, Вы писали:

K>Так частный случай же.


Массив простых типов — очень распространенный случай.

K>BSON был и быстрее и компактнее, чем JSON (обе реализации были от Newtonsoft).

K>Правда у нас в итоге победил json, упакованный в zip

Шо, и по скорости?
Ад пуст, все бесы здесь.
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: karbofos42 Россия  
Дата: 29.11.22 18:26
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Массив простых типов — очень распространенный случай.


Так в итоге всё в простые типы сериализуется.
Вопрос только в наборе данных, иерархиях и т.п.
Ну, как тут уже заметили: важен размер чисел. 1 в виде строки занимает меньше, чем 1 как int и т.п.

C>Шо, и по скорости?


Нет конечно. Так получилось, что важнее был объём, а время записи типа: 100 мс или 300мс — это не важно.
BSON и JSON по скорости записывались примерно одинаково, а вот чтение BSON проходило существенно быстрее.
Упакованный в zip JSON естественно сливал и в чтении и записи, т.к. там же сначала JSON генерируется (BSON совсем не сжимался).
Re[2]: JSON vs BSON: очередное торжество больного воображени
От: vdimas Россия  
Дата: 29.11.22 18:54
Оценка:
Здравствуйте, swame, Вы писали:

S>Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам

S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.

Можно было обыграть нестрогим JSON (это который в синтаксисе Java Script, где названия полей всегда латинница, числа без кавычек).
Тогда твой пример будет таким:
{
    Table: {
        Name: "Analogs",
        colCount: 7,
        rowCount: 10001
    },
    Columns: ["ID","Name","Path","Tag","Min","Max","Value"],
    CanWrite: [1,1,1,1,1,1,1],
    Rows: [
        [0,"analog_0",0,0,10,90,18],
        ...
        [10000,"analog_10000",100,10000,10,90,10]
    ]
}


То бишь, сохраняется структурированность описания, но выходит чуть компактней.

В синтаксисе JS порой намного удобней, бо можно вводить промежуточные значения:
part1 = { 
    A: 1, 
    B: 0 
};

part2 = { C: "X", D: ["Y", "Z"] };

config = { L: part1, M: part2 };

Что в развесистых описаниях резко повышает читабельность.

Хотя, если уж самим писать парсер, то я бы убрал синтаксическую избыточность:
part1: { A: 1 B: 0 }
part2: { C: "X" D: ["Y" "Z"] }
config: { L: part1 M: part2 }


Оно же с форматированием:
part1: { 
  A: 1 
  B: 0 
}

part2: { 
  C: "X" 
  D: [
    "Y" 
    "Z"
  ] 
}

config: { 
  L: part1 
  M: part2 
}


Т.к. оно и без лишних знаков препинания парсится всё тем же LR(1) парсером, который можно написать на коленке за вечер безо-всяких генераторов парсеров, т.к. просмотр всего на один шаг вперёд, то бишь каждый раз происходит простое ветвление на текущем токене.
Отредактировано 29.11.2022 18:56 vdimas . Предыдущая версия . Еще …
Отредактировано 29.11.2022 18:55 vdimas . Предыдущая версия .
Re[4]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: Codealot Земля  
Дата: 29.11.22 19:57
Оценка:
Здравствуйте, karbofos42, Вы писали:

K>Ну, как тут уже заметили: важен размер чисел. 1 в виде строки занимает меньше, чем 1 как int и т.п.


Если тупо всегда писать 32 бита, то да.

K>BSON и JSON по скорости записывались примерно одинаково


Даже и не близко.
Ад пуст, все бесы здесь.
Re[5]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: maxkar  
Дата: 30.11.22 20:56
Оценка: 3 (1)
Здравствуйте, B0FEE664, Вы писали:


BFE>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

А что вам по задаче нужно? У меня есть куча кирпичиков, я из них почти что угодно могу собрать. Из коробки есть три варианта. Первый просто скажет, что ваш JSON — валидный (валидация — частный случай парсинга). Второй построит
Json.Array(
  Json.Number("4294967297"),
  Json.Number("-4000000000"),
  Json.Number("18446744073709551617.0"),
  Json.Number("1.0000000000000...000"),
)

(нолики ограничил, но будут ровно те, которые в исходном массиве указаны). Дальнейшее поведение зависит от того, в какой именно тип нужно приводить значения (и нужно ли вообще) в программе. Например, в BigDecimal значения приведутся (и весь массив может быть преобразован в List[BigDecimal]). А вот в Int/Long — будут ошибки. Третий вариант очень похож на второй, но будет еще сохранять позицию в исходном файле. С помощью небольшой черной магии при преобразовании можно генерировать ошибки вида "<line>:<column>: значение по пути root(2) не является валидным целым числом" — есть как позиции в json, так и позиции в исходном тексте. А еще я могу собрать сразу все такие (валидный JSON-синтаксис но не соответствуют ожидаемой структуре) ошибки в один проход. Или не все, а, например, не более 42-х.

Парсеры ограничения по глубине не имеют (для типичного сценария в веб ограничения идут на длину потока, парсеру это не нужно), но легко сделать новый, с поддержкой такой фичи. Мегабайт вложенных квадратных скобок все парсыре разбирают, это вообще один из юнит-тестов. Можно собрать "инкрементальный" парсер — пришло нам 3Кб, мы их в парсер отправили и ожидаем следующих по сети. Во всех этих случах практически весь код переиспользуется (есть совсем небольшая разница в конструировании моделей на верхнем уровне, так оказалось удобнее, чем пытаться собрать универсальнй построитель). Всякие детали синтаксиса (формат чисел и т.п.) — полностью общие.

В общем, я учился (и вроде научился) декомпозировать синтаксис (тот же JSON) от всего остального: генерируемой модели, собираемых метаданных, обработки ошибок, потоков данных, синхронности/асинхронности вывода. Получились удобные кирпичики. В качестве побочного эффекта получился еще универсальный движок для корутин. Я потом на его базе сделал поддержку QoS для обработки http-запросов (например, admin получит приоритет и в выделении CPU, и в доступе к SQL-соединениям в пуле), но это уже совсем другая история.
Re[3]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: νsb Казахстан  
Дата: 30.11.22 23:42
Оценка:
Здравствуйте, B0FEE664, Вы писали:

КБ>>Собственно в текстовом представлении json минимум накладных расходов на самом деле.

BFE>Json очень сложно парсить. Я не уверен, что существует хотя бы один парсер который делает это корректно. Вот известная статья по проблемам Json.

Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.
Re[6]: JSON vs BSON: очередное торжество больного воображения и кривых рук
От: B0FEE664  
Дата: 01.12.22 10:57
Оценка:
Здравствуйте, maxkar, Вы писали:

BFE>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:

M>А что вам по задаче нужно?
Речь не про задачу, речь про стандартизованный формат — он крайне, просто на редкость неудобный: числа выделены в отдельный тип данных, но целые числа не отличаются от чисел с плавающей точкой, зачем-то выделен отдельный тип boolean и загадочное значение null, которое можно было бы заменить отсутствием значения { "x":null } <=> { "x": }. При этом умудрились упустить из виду некоторые простейшие формы записи чисел (типа 1.), которые широко используются, но не стандартны. Не удосужились ввести ограничения на значения.

M>Парсеры ограничения по глубине не имеют

Любопытно, сколько времени ушло на написание парсера и сколько строк кода он содержит?
И каждый день — без права на ошибку...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.