Информация об изменениях

Сообщение Re[7]: JSON vs BSON: очередное торжество больного воображени от 20.03.2023 19:11

Изменено 20.03.2023 19:17 swame

Re[7]: JSON vs BSON: очередное торжество больного воображени
Здравствуйте, ·, Вы писали:

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


·>Непонятно засчёт чего. "0,analog_0,0,0,10,90,18" практически такого же размера как и [0,"analog_0",0,0,10,90,18]. Ну и зипануть можно. И разницы в микроскоп не заметишь.


В файле разницы и правда не заметишь, а в памяти DOM разница будет на порядок.

Но я сравниваю не с этим а с обычным json
ID="0"
Name="analog_0"
Path=""
Tag="0"
Min="10"
Max="90"
Average="55"
Value="18"

·>Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...


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

S>>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.

S>>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
·>Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).

Да, я положу в массив, который будет существовать только на момент парсинга, а парсер в коллекцию Key/Value, индексированную или нет в зависимсоти от реалицации, и занимающую кучу памяти, и будут они все занимать память одновременно до уничтожения DOM

·>С DOM хорошей скорости вообще практически никак не обеспечить.


Пока хватает без лищней сложности, перестанет хватать — перейду на поточный.
К тому же иногда DOM намного удобней, например для внесения точечных изменений — распарсил, нашел узел, изменил, сохранил обратно.

S>>Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.

·>Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.

Ну считай, я долго рылся с этой куче грязи и подобрал "стандартный" формат для упаковки атрибутов,
подходящий мне по всем критерям, тебе легче от того что он "стандартный", ведь реализации в разных либах на практике будут отличаться в нюансах.
Re[7]: JSON vs BSON: очередное торжество больного воображени
Здравствуйте, ·, Вы писали:

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


·>Непонятно засчёт чего. "0,analog_0,0,0,10,90,18" практически такого же размера как и [0,"analog_0",0,0,10,90,18]. Ну и зипануть можно. И разницы в микроскоп не заметишь.


В файле разницы и правда не заметишь, а в памяти DOM разница будет на порядок.

Но я сравниваю не с этим а с обычным json
ID="0"
Name="analog_0"
Path=""
Tag="0"
Min="10"
Max="90"
Average="55"
Value="18"

·>Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...


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

S>>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.

S>>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
·>Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).

Да, я положу в массив, который будет существовать только на момент парсинга, а парсер в коллекцию Key/Value, индексированную или нет в зависимсоти от реалицации, и занимающую кучу памяти, и будут они все занимать память одновременно до уничтожения DOM

·>С DOM хорошей скорости вообще практически никак не обеспечить.


Пока хватает без лищней сложности, перестанет хватать — перейду на поточный.
К тому же иногда DOM намного удобней, например для внесения точечных изменений — распарсил все, нашел узел, изменил, сохранил обратно.

S>>Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.

·>Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.

Ну считай, я долго рылся с этой куче грязи и подобрал "стандартный" формат для упаковки атрибутов,
подходящий мне по всем критерям, тебе легче от того что он "стандартный", ведь реализации в разных либах на практике будут отличаться в нюансах.