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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не программист ни разу, не надо тут мне предъявлять.

Зачем я залез на этот гадюшник?

https://i.playground.ru/i/pix/593085/image.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По бенчмаркам парсинга жсона глянь репу simdjson.

100000 конфигов по 1киллобайту

оверхед x100000 на пустом месте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шутка

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

От слова "лень" однако ...

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

https://www.meme-arsenal.com/memes/fdb412d5b0c528b251174426e5cd9586.jpg

https://www.google.ru/imgres?imgurl=http%3A%2F%2Fsun9-4.userapi.com%2Fimpf%2Fc846419%2Fv846419979%2F10edf9%2FZY5IWckAcOU.jpg%3Fsize%3D503x604%26quality%3D96%26sign%3De731e308cbae6e267807231c7f0c2f4b%26type%3Dalbum&imgrefurl=https%3A%2F%2Fvk.com%2Fwall-9957744_953513&tbnid=04vKhMa_CvDUQM&vet=12ahUKEwiI3_i2hsTzAhVrl4sKHf4ECE4QMygEegUIARCTAQ..i&docid=MVZw2YPFueV6rM&w=503&h=604&q=%D0%BB%D0%B5%D0%BD%D0%B8%D0%BD%20%D1%84%D0%BE%D1%82%D0%BE%20%D0%B3%D0%B0%D1%80%D0%BC%D0%BE%D1%88%D0%BA%D0%B0&ved=2ahUKEwiI3_i2hsTzAhVrl4sKHf4ECE4QMygEegUIARCTAQ

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

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

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

Экспромтом.

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

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

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

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

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

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

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

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

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

… а лор меня научил, что, оказывается, лучше жсона формата нету.

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

Может он просто из 2002 пишет.

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

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

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

не годятся

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

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

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

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

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

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

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

Нет парсера, который бы мог извлечь из него нужные метаданные

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

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

Если про json...

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

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

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

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

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

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

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