Сообщение Re[7]: JSON vs BSON: очередное торжество больного воображени от 20.03.2023 19:11
Изменено 20.03.2023 19:16 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="0"
Max="0"
Value="0"
·>Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...
Я не против событийного, когда понадобится по скоростным характеристикам, но сложность работы с ним будет точно не меньше , чем с моим форматом.
S>>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.
S>>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
·>Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).
Да, я положу в массив, который будет существовать только на момент парсинга, а парсер в коллекцию Key/Value, индексированную или нет в зависимсоти от реалицации, и занимающую кучу памяти, и будут они все занимать память одновременно до уничтожения DOM
·>С DOM хорошей скорости вообще практически никак не обеспечить.
Пока хватает без лищней сложности, перестанет хватать — передй на поточный
S>>Да, я такие случаи отрабатываю, и более сложные. наверняка найдутся супернавороченные, котороые я не обрабатываю, пока не встретились, но и в этом топике приведена куча примеров, которые json не пережевывает.
·>Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.
Ну считай, я долго рылся с этой куче грязи и подобрал "стандартный" формат для упаковки атрибутов,
подходящий мне по всем критерям, тебе легче от того что он "стандартный", ведь реализации в разных либах на практике будут отличаться в нюансах.
·>Здравствуйте, 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="0"
Max="0"
Value="0"
·>Ну кто ж такое DOM-ом парсит.. Возьми событийный парсер и раскладывай в памяти как угодно...
Я не против событийного, когда понадобится по скоростным характеристикам, но сложность работы с ним будет точно не меньше , чем с моим форматом.
S>>При обработке (на последнем, самом объемном уровне дерева)вместо создания хэш таблицы или поиска перебором по атрибуту идет обращение к элементу массива.
S>>Мой маленький парсер достаточно быстрый. Естественно, его работа включена в общий замер.
·>Не понял. Как к элементу строки "0,analog_0,0,0,10,90,18" по индексу обратишься? Придётся пропарсить и разложить в массив (т.е. сделать работу json-парсера).
Да, я положу в массив, который будет существовать только на момент парсинга, а парсер в коллекцию Key/Value, индексированную или нет в зависимсоти от реалицации, и занимающую кучу памяти, и будут они все занимать память одновременно до уничтожения 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 не пережевывает.
·>Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.
Ну считай, я долго рылся с этой куче грязи и подобрал "стандартный" формат для упаковки атрибутов,
подходящий мне по всем критерям, тебе легче от того что он "стандартный", ведь реализации в разных либах на практике будут отличаться в нюансах.
·>Здравствуйте, 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 не пережевывает.
·>Если это какой-то особый случай, достаточно взять более подходящий формат, их как грязи, а изобретать ещё один — моветон.
Ну считай, я долго рылся с этой куче грязи и подобрал "стандартный" формат для упаковки атрибутов,
подходящий мне по всем критерям, тебе легче от того что он "стандартный", ведь реализации в разных либах на практике будут отличаться в нюансах.