LINUX.ORG.RU

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

 , , , ,


1

2

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

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

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

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

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

Всё норм. Ну если джсоны всякие такое не переваривают (сомневаюсь) то конфиг поменьше =) Главное тут сколько мегабайт они могут обработать за 1 секунду например.

LINUX-ORG-RU ★★★★★ ()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от Yorween

Тут что-то не так xD

некоторые кормят рыбок. некоторые голубей. некоторые кошек и белочек…

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

alysnix ★★ ()
Ответ на: комментарий от LINUX-ORG-RU

Главное тут сколько мегабайт они могут обработать за 1 секунду например.

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

alysnix ★★ ()

гигабайтный конфиг

С пятницы на просыхаешь?

Во-первых, причём тут конфиги? Во-вторых, тебе нужен поточный парсер, бери lxml.

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

Во-вторых, тебе нужен поточный парсер, бери lxml.

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

alysnix ★★ ()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

С пятницы на просыхаешь?

Из спиртосодержащего балуюсь только кефиром ващет

Во-первых, причём тут конфиги?

Ну просто форматы, кто-то lua как фонфигурацию использует. Кто-то json для хранения порой не маленьких obj данных (привет WebGL). Вот это вот всё. Любая человеко редактируемая хня которая умеет в древовидное представление данных и может хранить единичные значения, массивы. Интересует просто что их них как бы это сказать универсальных инкапсуляторов данных во! гыгыгы работет тупо быстрее. При например обработке я хз большого конфига с базой данных погоды всех городов мира за неделю. То есть не тупа непрерывный поток данных, а всё же какое ни какое разбитие на множества полей ну и всё вот такое.

LINUX-ORG-RU ★★★★★ ()
Ответ на: комментарий от alysnix

Кукушечку поправь и перечитай топик. Гигабайтный конфиг, Карл. Нет, точно ни о каких конфигах не идёт, ТСа просто переклинило, протркзвеет и осознает.

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

Да блин, не пью я. И не ширяюсь. Ладно давай без гигабайтов тупо кто быстрее. Допустим у меня 100000 конфигов по 1киллобайту. Кто переработает быстрее с учётом того что они уже в памяти все.

LINUX-ORG-RU ★★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

Много ты кефига выдул, однако. Смотри чтобы не разорвало.

То, о чём ты говоришь, это просто набор данных, а не конфиги. Юзай XML лучше, не дури.

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

Нет, точно ни о каких конфигах не идёт, ТСа просто переклинило, протркзвеет и осознает.

тс просто желает получать некие обьемные структурированные данные в некоем формате и парсить их. ну называет это «конфигами»…вон мировая погода ему понадобилась. другому понадобятся биржевые котировки, третьему - данные по поросячьим бегам.

и это жисон, если нужен формат текстовый.

alysnix ★★ ()
Ответ на: комментарий от LINUX-ORG-RU

node. Асинхронно, chunks, размер можешь сам выбирать.
Видно, что специалисты на ЛОР - моветон.

Давеча парсил файло под свои задачи, мегабайт 50 текста посимвольно - пару секунд.

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

А как ты данные подготавливать собрался, кстати? И в каком виде они будут в памяти? Мб не стоит изобретать велик и тупо юзать cPickle?

WitcherGeralt ★★ ()
Ответ на: комментарий от LINUX-ORG-RU

То есть не тупа непрерывный поток данных, а всё же какое ни какое разбитие на множества полей ну и всё вот такое.

А какая разница? Stream для кого придумали? Зачем я залез на этот гадюшник? МЕГОПРОГРАММИСТЫ, блядь.

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

Именно так. Только я хочу знать что из существующего быстрее всего работает. Json быстрый, но если TOML бытрее (его/их) реализации значит TOML лучше если для libconfig описать теже данные и он их переварит быстрее этих двух значит лучший libconfig и так далее.

LINUX-ORG-RU ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Данные от кучи такого например, вот так и подготовлены

section
{
   key{
        subkey{
                  value=-42
                  veclue2=42,42,42,42,42,42,42,2,42,42,42,42
                  ...
                  value100500;
              }
        ....
        subkey10500{
                  value=-42
                  veclue2=42,42,42,42,42,42,42,2,42,42,42,42
                  ...
                  value100500="hello";
                  value1005001 {name=masha,age=42,....chto_kushala_na_obed="kartoshka"}
              }
   }
}

И в каком виде они будут в памяти?

Загружены в память заранее в виде массива/вов. Или mmap`нуты если большие. Никакой задержки в получении данных (исключая время на загрузку в память) нет.

Мб не стоит изобретать велик и тупо юзать cPickle

Ладно так и быть скажу (только никому больше не говори!) что в том и дело что я изобретаю свой велик и хочу выяснить есть ли в этом смысл. Если есть что-то адекватное быстрее моего то я выберу это.

И да сишка онли. Забыл в начале указать, ну да пофиг.

LINUX-ORG-RU ★★★★★ ()

Вообще. Я 15 лет уже в ИТ.

На моей памяти было:

  1. Работа с данными в бинарных файлах. В т.ч. своего формата

2.XML. его все боготворили за то что можно редактировать юзеру в блокнотике. Это был прорыв по сравнению с бинарными файлами.

  1. Ini-файлы. Их привнесла винда. Особо по ним не упарывались. Но потихоньку стали применять.

  2. SQL БД. Как локальные типа dbf так и серверные. Веб в нулевых почти весь был на реляционных БД.

  3. NO SQL БД. Монго. Редиска.

  4. SQLITE БД. Отдельно я её прописал поскольку это революционнпя либа. В одном ряду с jquery, bootstrap, pcre и другими великими вещами.

  5. С распространением скриптовых языков стали делать конфиги в виде простых файлов этого же скриптового ЯП. Оказалось очень удобно.

  6. Появились аналоги XML. Это JSON, YAML. Есть любители и таких форматов файлов конфигурации.

  7. Ну и наконец, король всех буратин - самодельный текстовый формат конфигурации. Каюсь, делал для человека прогу Life на Qt C++ и придумал свой текстовый формат файла. Если на текстоаые файлы применить Sphynx или ElasticSearch то может побегать и очень шустро.

Итак. Для Вас. В случае если данных у Вас прямо так гигабайт! Советую «жирную» БД типа postgresql или придумать свой бинарный формат файла. Остальные подходы не так эффективны или имеют другие недостатки.

Дополню. Почти все перечисленные мною подходы к работе с конфигами поддерживают древовидные данные. Даже SQL - БД. ЕМНИП в энтерпрайзных БД даже есть тип хранения данных сразу в виде дерева, без необходимости эмулировать его через таблицы.

pup_kin ()
Последнее исправление: pup_kin (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

У меня была ситуация когда в мобильном браузере я загружал json из файла размером 50 МБ. Это был предел, больше не хватало памяти (после парсинга)

Сначала я думал заменить json на bson или MessagePack но потом перешёл к базе данных.

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

Конечно моооожно sqlite какой заюзать. Но уж слишком много мороки. Сейчас интересуют текстовые. Если мне надо будет бинари я прямо ф вайл и буду писать [имя][смещение на родителя][размер смещения на новую позицию][данные][следующее имя]и так далее прямо в бинарном виде. Ну и в заголовке все кулючи все смещения на дочек и родителей. И всё будет леать быстрее любой реализации иной. Но это бинари, хоца текст и что из текстового самое вжуууууууухъ узнать =)

LINUX-ORG-RU ★★★★★ ()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Такие объёмы лучше не запихивать в sqlite. Это ужэ для дибиту или оракл задача. Ну или монго с редиской, если вы сумеете свои данные в их понятия трансформировать.

pup_kin ()
Ответ на: комментарий от LINUX-ORG-RU

Я использовал localforage (обёртка для хранения данных на фронтенде) сначала, теперь в основном tinydb (это питоновская либа, хранящая данные в json файле, скорости тут нет)

Думаю в вашем случае двоичный файл лучшее решение. Для bson есть готовые конвертеры в json, и формат простой. То есть возможность редактировать останется, путем двойной конверсии.

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

Млин быстро. Конечно надо на своей машинке прогнать ещё эти же тесты вероятно будет в разы всё скромнее, но пока 2,5 гига в секунду мощна. Мой велосипед лопатит 100 метровый файл в виде 57958 блоков данных по 2х вложенных ключей с 12 полями из массивов за 1.978147 секунды. На феноме 2 2800Mhz

LINUX-ORG-RU ★★★★★ ()
Ответ на: комментарий от anonymous

А да пофиг их можно загрузить в 1 буфер разом. А потом просто по смещению передавать на обработку. Да и вообще это просто пример =)

LINUX-ORG-RU ★★★★★ ()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от alysnix

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

Мог бы быть, если бы не обязательное заковычивание ключей, даже если там валидные идентификаторы; все мои собственные парсеры (UPD: и сериализаторы) json это ограничение ослабляют.

dimgel ★★★★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

Мог бы быть, если бы не обязательное заковычивание ключей,

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

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

Вот когда крякозябры, тогда я и квочу. Но в подавляющем большинстве случаев (если не сказать: у нормальных людей – всегда) там либо идентификаторы, либо числа. И квоченье в этом случае – дико раздражающий визуальный шум при чтении, и пальцедробительная хрень при набирании. Только взять любой ini-файл на системе, и представить, что в нём все имена свойств будут заквочены – да ну нахрен такие конфиги.

dimgel ★★★★★ ()

Смотрите какие библиотеки используют известные проекты …

И не ошибетесь в выборе!
anonymous ()

Хочешь быстроту, делай свой бинарный формат заточенный под конкретные потребности.

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

Хочешь быстроту, делай свой бинарный формат заточенный под конкретные потребности

Хороший совет.
Только вот лучше разработать API, позволяющего создавать и работать с любыми бинарными объектами в run-time.

Сэкономите тонны времени при разработке алгоритмов

Ныне правда все используют сериализацию /от своей лености/ …

Шутка

Многие не знают откуда появился псевдоним Ленин

От слова "лень" однако ...
anonymous ()
Ответ на: комментарий от LINUX-ORG-RU

Что бы например им скармливали гигабайтный конфиг …

А он шо задает свойства всей вселенной?

anonymous ()

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

Экспромтом.

Не знаю ответ на этот вопрос.
Как вариант посмотрите как в Postgress парсится JSON, а заодно и использование JSONB …

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

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

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

byko3y ★★★★ ()

Где ты гигабайтные конфиги видел?

Обычно вообще не парятся по поводу скорости парсера, т.к. это за доли секунды выполняется.

Может, тебе ещё аргументы командной строки надо оптимально парсить?

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

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

https://en.wikipedia.org/wiki/False_dichotomy

https://en.wikipedia.org/wiki/YAML, https://en.wikipedia.org/wiki/TOML, https://dhall-lang.org, …

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

YAML нельзя просто так проецировать на лучше/хуже, он слишком лунатичен.

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

не годятся
anonymous ()
Ответ на: комментарий от t184256

YAML нельзя просто так проецировать на лучше/хуже, он слишком лунатичен.

его явно разрабатывали не программеры, а вебдизайнеры или хуже того.

все ходовые способы описания и структурирования данных есть в ходовых языках програмирования. и не надо нам новых подходов и чудовищных кракозябр с неким внутренним смыслом. от смыслов итак голова пухнет.

alysnix ★★ ()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

ну да, надо запятые, синтаксические ошибки по поводу их избытка и отсутствие комментов.

всему свое применение.

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

Шутка на > Некоторые используют их в качестве метаданных, но они для этого

Лучший формат представления метаданных это обычный рукописный текст.
Одна мета

Нет парсера, который бы мог извлечь из него нужные метаданные
anonymous ()
Ответ на: комментарий от LINUX-ORG-RU

Хотя не, не быстро. Моя поделка теже данные молотит со скоростью 9.5 GB/s и без всяких simd на лапше switch/case без goto

LINUX-ORG-RU ★★★★★ ()

Протобуф еще рассмотри.

Reset ★★★★★ ()

Если про json...

Судя по тому, как подготовлены данные, на него и похоже.

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

То вроде даже и есть. Насколько актуально на данный момент не знаю, судя по дате публикации это писалось в 2012г.

И да, придётся mmap() использовать. Если данные неизменяемые. Если изменяемы (чтение-запись-удаление, вот это вот всё), то либо постгри, либо berkeley db использовать.

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

Moisha_Liberman ★★ ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: комментарий от anonymous

Некоторые используют их в качестве метаданных, но они для этого не годятся

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

kolpakchi ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.