BSON, бинарный формат — по идее должен быть компактее и быстрее.
На практике, пишем простейший массив чисел:

            var data = new int[count];
            for (var i = 0; i < data.Length; i++)
            {
                data[i] = i;
            }
            
            ...

BSON — в 3.85 раза медленее чем JSON и файл получается в 1.6 раза больше.

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

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

C>BSON, бинарный формат — по идее должен быть компактее и быстрее.
C>На практике, пишем простейший массив чисел:
C>BSON — в 3.85 раза медленее чем JSON и файл получается в 1.6 раза больше.

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

BSON is also designed to be fast to encode and decode. For example, integers are stored as 32 (or 64) bit integers,

Поэтому, то что результат будет больше при записи чисел от 0 до N, неудивительно,
при N < 100, каждое число в JSON будет занимать 2 байта, а в BSON 4 байта.

А вот что это работает медленнее, это скорее претензии к C#,
почему у него простое копирование занимает времени больше чем перевод текста в число.

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

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

С чего бы ему быть компактнее

"1,2,3,4,5,6,7,8,9,10" — 20 байт
"01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 00 00 00 0A 00 00 00" — 40 байт
Если 64-битные числа хранить уже все 80 байт будет.

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

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

Z>Поэтому, то что результат будет больше при записи чисел от 0 до N, неудивительно,
Z>при N < 100, каждое число в JSON будет занимать 2 байта, а в BSON 4 байта.

На самом деле, N = 0x2_000_000

Z>А вот что это работает медленнее, это скорее претензии к C#,
Z>почему у него простое копирование занимает времени больше чем перевод текста в число.

Фигня. Простая запись бинарных чисел без каких-либо попыток оптимизации получается в 4.5 раза быстрее и в 2.16 раза компактнее, чем JSON. Ну а во сколько раз быстрее и компактнее чем BSON, можно и вообще не говорить

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

КБ>Если 64-битные числа хранить уже все 80 байт будет.

Как нетрудно убедиться из кода, числа 32-битные.

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

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

Непонятно, зачем он тебе вообще нужен. Гонять числа по сети? Если это СУБД, то наверняка там тонны ТЕКСТОВЫХ данных, а значит пользы от BSON ноль. Если же данные специфичные (числа), опять же зачем BSON — посмотри на задачу и подумай, может тупо записать массив в файл?

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

B>Непонятно, зачем он тебе вообще нужен.

С такими скоростями и объемами — нафиг не нужен. И я с трудом представляю, кому и зачем он такой может быть нужен

Размер надо сравнивать после gzip-а. Скорость — скорей всего недоработка реализации. В целом не вижу места никаким форматам общего назначения кроме JSON.

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

C>BSON — в 3.85 раза медленее чем JSON и файл получается в 1.6 раза больше.

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

Я в итоге в поисках компромисса между читаемостью, расширяемостью, скоростью, размерам
пришел к псевдо-JSON Формату, где записи пакуются в строку, а названия полей описываются 1 раз.
По сути, возврат к тому же CSV, но в одном файле можно описать несколько структур разного формата.
По скорости когда- то мерял, сериализация / десериализация по скорости в районе 400 Mb/c.
Но без всяких reflection.
От идеи бинарного формата давно отказался, по причинам , которые уже объяснили.

{
    "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",
        "1,analog_1,0,1,10,90,97",
        "2,analog_2,0,2,10,90,25",
        "3,analog_3,0,3,10,90,81",
        "4,analog_4,0,4,10,90,43",
        "5,analog_5,0,5,10,90,88",
     ...
      "9999,analog_9999,99,9999,10,90,29",
        "10000,analog_10000,100,10000,10,90,10"
    ]
}

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

C>BSON — в 3.85 раза медленее чем JSON и файл получается в 1.6 раза больше.

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

Зачем использовать BSON, когда есть MessagePack, Protobuf и прочий Thrift?

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

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

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

R>Зачем использовать BSON, когда есть MessagePack, Protobuf и прочий Thrift?

А ты думаешь, что они сильно лучше?

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

C>А ты думаешь, что они сильно лучше?

Для сериализации массива интов что Protobuf, что MessagePack будут существенно лучше BSON,
достаточно посмотреть спецификацию — BSON, Protobuf, MessagePack.
А если нужна сериализация конкретно массивов интов, то можно смотреть что-то специфическое, типа FastPFOR

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

R>>Зачем использовать BSON, когда есть MessagePack, Protobuf и прочий Thrift?

C>А ты думаешь, что они сильно лучше?

Думаю, что Protobuf точно сильно лучше

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

R>Для сериализации массива интов что Protobuf, что MessagePack будут существенно лучше BSON,

Там много всего кроме массивов, просто они самые объемистые.

R>А если нужна сериализация конкретно массивов интов, то можно смотреть что-то специфическое, типа FastPFOR


Для такой примитивной задачи мне не нужны никакие библиотеки.

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

R>Для сериализации массива интов что Protobuf, что MessagePack будут существенно лучше BSON,

Попробовал. Лучше чем BSON, но все равно хуже чем самый примитивный неоптимизированный велосипед.

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

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

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

Вообще я имел в виду именно размер представления, но и со сложностью парсинга согласиться нельзя. Написать корректный парсер json — тривиально.
Даже хитрые тесты этого исследователя большинство реализаций проходит http://seriot.ch/json/parsing_pruned.html#all_results

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

R>>Зачем использовать BSON, когда есть MessagePack, Protobuf и прочий Thrift?

C>А ты думаешь, что они сильно лучше?

Есть большое сравнение по перформансу с этими форматам/либами. Погугли. Под рукой нет ссылки. Подозреваю, в твоем случае либа BSON сильно корявая.

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

КБ>>>Собственно в текстовом представлении json минимум накладных расходов на самом деле.
BFE>>Json очень сложно парсить. Я не уверен, что существует хотя бы один парсер который делает это корректно. Вот известная статья по проблемам Json.
КБ>Вообще я имел в виду именно размер представления, но и со сложностью парсинга согласиться нельзя. Написать корректный парсер json — тривиально.
КБ>Даже хитрые тесты этого исследователя большинство реализаций проходит http://seriot.ch/json/parsing_pruned.html#all_results

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

Если вы внимательно посмотрите на приведённую таблицу, то увидите, что там нет ни одного парсера удовлетворяющего следующим условиям:
1) парсер не должен падать на любых входных данных
2) парсер должен разбирать данные за конечное время
3) парсер должен успешно разбирать корректные данные

вот тут из 63 (если я правильно подсчитал) парсеров остаются только 32, т.е. половина. Причем большая часть — это разные версии одних и тех же парсеров.

Если добавить требование:
4) парсер должен выдавать ошибку, если данные не корректны, то останется 9 парсеров

И добавив последние требование:
5) для всех таких данных, для которых результат является неопределённым, парсер должен либо выдавать ошибку, либо успех. Другими словами: либо все неопределённые результаты — успех, либо ошибка, но не так, что часть данных разбираем, а для части выдаём ошибку.

В итоге получаем что нет ни одной корректной реализации.
А ещё в этих тестах рассмотрены не все случаи. Например, там не рассмотрен случай, типа 0.1E+0000000000000000000...(очень много нулей)...0001 — единица представима как число на любой платформе, а значит парсер должен (в соответствии с rfc7159) разобрать это число без ошибок даже если по длине записи данное число превышают гигабайт, скажем. Ведь здесь нет выхода ни за пределы точности, ни за лимиты представления чисел.


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

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

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

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

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

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

BFE>Если добавить требование:
BFE>4) парсер должен выдавать ошибку, если данные не корректны, то останется 9 парсеров

BFE>И добавив последние требование:
BFE>5) для всех таких данных, для которых результат является неопределённым, парсер должен либо выдавать ошибку, либо успех. Другими словами: либо все неопределённые результаты — успех, либо ошибка, но не так, что часть данных разбираем, а для части выдаём ошибку.

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

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

Ошибку конечно же.