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

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

Компактный формат, быстрый формат и формат с поддержкой обратной/прямой совместимости данных — это, как правило, три разных формата.

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

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

Так частный случай же. Я как-то сравнивал на своих реальных объектах JSON и BSON (благо там пару строк кода всего поменять нужно).
BSON был и быстрее и компактнее, чем JSON (обе реализации были от Newtonsoft).
Правда у нас в итоге победил json, упакованный в zip

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

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

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

S> Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам
S>пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
Прикольно
Работая с электронным документооборотом в бюджетной сфере, я насмотрелся всяких текстовых структурированных форматов. Запомню и этот в своей копилке возможного

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

BFE>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:
BFE>>[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000...000000000000000000000000000000000000000000]
R>Image: aekPFxJ0eeE.jpg

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

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

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

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

Здравствуйте, Константин Б., Вы писали:

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

BFE>>А в накладные расходы входит сложность и корректность парсинга.
КБ>JSON.parse(x) — для меня достаточно просто.
И что там с корректностью?

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

BFE>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:
BFE>>[4294967297, -4000000000, 18446744073709551617.0, 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000]
КБ>Ошибку конечно же.
Ошибку или ошибочный результат

Автор: rollcoin
Дата: 29.11.22

?

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

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

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

Здравствуйте, 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

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

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

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

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

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

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

Ну, т.е. это нормально — никакой надёжности, зато просто.

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

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

Ну разумеется.
В результате нормальные программы передают в Json только строки. И числа передают строками, а уж потом сами парсят строки в числа.
Потому как формат дебильный.
Чего стоит одно то, что число 1. является некорректной записью!

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

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

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

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

Newtonsoft.Json.Bson

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

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

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

K>BSON был и быстрее и компактнее, чем JSON (обе реализации были от Newtonsoft).
K>Правда у нас в итоге победил json, упакованный в zip

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

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

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

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

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

Нет конечно. Так получилось, что важнее был объём, а время записи типа: 100 мс или 300мс — это не важно.
BSON и JSON по скорости записывались примерно одинаково, а вот чтение BSON проходило существенно быстрее.
Упакованный в zip JSON естественно сливал и в чтении и записи, т.к. там же сначала JSON генерируется (BSON совсем не сжимался).

Здравствуйте, 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) парсером, который можно написать на коленке за вечер безо-всяких генераторов парсеров, т.к. просмотр всего на один шаг вперёд, то бишь каждый раз происходит простое ветвление на текущем токене.

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

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

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

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

Даже и не близко.

Здравствуйте, 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-соединениям в пуле), но это уже совсем другая история.

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

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

Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.

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

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

M>Парсеры ограничения по глубине не имеют
Любопытно, сколько времени ушло на написание парсера и сколько строк кода он содержит?