LINUX.ORG.RU

Производительность реализаций парсинга конфигурационных форматов

 , , , ,


1

2

Интересует большая табличка сравнения скорости парсинга различных древовидных форматов конфигураций в разных реализациях. Json например и json-c,jansson иное. TOML например и его реализации. libconfig и так далее. Что бы например им скармливали гигабайтный конфиг и сколько мегахешей мегабайт с секунду они обрабатывали.

Да я гуглю прямо сейчас, но какие то рандомные тесты непонятные везде. Хочется сравнения в один ряд и форматов и реализаций при обработке одних и тех же данных.

Ну вот например https://github.com/serde-rs/json-benchmark/blob/master/README.md только по множеству разных форматов и их реализаций хочется увидеть.

UDP: Короче масштабных сравнений нету в природе вроде

★★★★★

Последнее исправление: LINUX-ORG-RU (всего исправлений: 4)

Ответ на: комментарий от kolpakchi

А что годится? Для моих целей json даже избыточен, мне нужны только объекты и строки.

По конкретней пожалуйста … /не понятно о чем речь/

anonymous
()
Ответ на: комментарий от anonymous

Sorry

Поконкретней пожалуйста … /не понятно о чем речь/

anonymous
()
Ответ на: комментарий от anonymous

Допустим, я захотел сделать свой аналог куба для stm32 и не только. Это примерно чем я сейчас увлекаюсь. Как лучше хранить объекты с описанием регистров (смещение, имя, длина, ссылка на родителя, ссылки на детей и др)? Сейчас у меня база данных на основе json (tinydb). В предполагаемом будущем будет message pack. Я думаю никто не будет спорить, что информация о регистрах это самые настоящие метаданные.

Вот и вопрос: как их лучше хранить, есть ли универсальные ответы или решения?

kolpakchi
()

Подключал lua, он от природы предназначен чтоб на нем можно было файлы данных делать. Парсит себя сам. Гигабайтный конфиг на луа всех обгонит

pihter ★★★★★
()
Ответ на: комментарий от kolpakchi

Вот и вопрос: как их лучше хранить, есть ли универсальные ответы или решения?

Универсальных ответов пока нет.
Что до того «как», смотрите и анализируйте разные форматы бинарного представления данных.

Их море!

Например разработчики 1С 7.7 использовали алгоритмы сериализации и десериализации из MFC … Почитайте о native представления данных в protobuffer, b-tree, B+ деревьях, …, использовании хэшей.
Вам нужно понять СУТЬ, а затем уже сможете сами проектировать эффективные объекты …

anonymous
()
Ответ на: комментарий от kolpakchi

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

А потом я подумал: ну какой идиот будет конфиг писать такой длины? Ну от силы же сотня-другая строчек!!! Их можно вообще в лоб тупо разбирать, ты даже моргнуть не успеешь, как самая тупая реализация все сделает. Хоть на пытхоне!

anonymous
()
Ответ на: комментарий от alysnix

жысон идеален для конфигов

не, ну жысонь канеш лучче ямла́, но по сравнению с edn - увы

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.