Easyelectronics.ru

В кои то веки мне дали выбор - выбери документ для парсинга а мы его заполним данными.
Инструмент для парсинга - С.
И я задумался какой документ быстрее распарсить? До сих пор я парсил в основном три формата - ini, xml, comma separated
но я никогда не задумывался какой из них лучше парситься по скорости (в данном случае определяющий фактор - скорость).
Может кто то проводил такой анализ?

XML однозначно самый медленный (а если по всем правилам парсить, то еще и достаточно сложный) формат для парсинга. ini для данных подходит слабо, а вот CSV, пожалуй, самый простой и быстрый. Хотя нужно учесть некоторые частные случаи, типа текста с запятыми внутри.

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

спасибо. это в принципе конфигурационный файл. около 80-100 переменных. некоторые строковые.

Конкретно в этом случае, INI с секциями будет удобнее и читабельнее. Особенно если разбить переменные на категории и категории положить в секции. Что-то типа такого:


В плане парсинга сильно большой разницы в скорости нет. На выходе можно формировать имена переменных из секции и собственно имени, типа input.vmax. Результат парсинга удобно складывать в какой-нибудь контейнер, типа hash map или сразу устанавливать переменные в программе.

спасибо.

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

CSV

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

Тогда чего тебя скорость беспокоит? 80-100КБ инишник в худшем случае должен парситься за тысячные доли секунды, хотя у меня за столько уже компилятор из таких файлов байткод генерит :)

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

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

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

Здесь не о скорости надо думать, а о том, насколько человеку удобно. И, естественно, выбор будет не в пользу XML. Либо JSON, либо ini. В простейшем случае — параметр=значение.

спасибо. а то я тут свой огород городить начал.

кстати тут возник еще один вопрос - строка прочитанная из файла - это всегда строка? нужно делать atoi() чтоб получить число?

atoi об ошибках ничего не скажет, надо пользоваться strtod, strtof и т.п.

А почему нельзя на нормальном компьютере проверить разные способы ?
Померять скорость, посмотреть кол-во строк для реализации, а потом на мелком окончательно протестировать.

да но меня интересует сам принцип. есть скажем файл, который вернет 1234 а не 31 32 33 34?

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

Какой-то странный вопрос. Если у вас в файле записано 0x31323334, то почему-то это должны видеть как-то иначе? Запишите в файл 0x04 0xD2 и при чтении этих 2байт увидите число 1234. Только файл уже будет не текстовым, а бинарным, т.к. 0x04 уже управляющий символ если по ASCII. Вы когда сохраняете именно текст 1234, то редактор и переводит его в последовательность ASCII (или любой другой кодировки) 31 32 33 34. Для компа там нет 1234 уже, там именно 31 32 33 34. Именно для этого и нужны функции обратного преобразования.

Да тема вообще странная.
Если уже 3 формата парсил, то что мешает померить скорость (если она важна) или размер кода.
Можно эмулятор взять для отладки кода/алгоритма.
Если проверка на большом компьютере вызывает сложности.

Пока вы не сделаете многопоточную (или многопроцессорную) обработку, все будет выполняться на одном ядре в любой момент времени.

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

понял. спасибо.

Если это конфигурационный файл, то непонятно, почему критична скорость...

На самом деле, для этой задачи... Разницы между ними практически нет.

Напрашивается ini: и парсится не особо сложно и редактировать не утомительно. А самое плохое что я видел - какой-то длинк хранил конфиг в XML. Пять килобайтов одной строкой. Редактировать его было крайне мучительно. Можно конечно переформатировать, но он при изменении чего либо из вебморды все-равно вернет вид конфига в этот ужас. Не делайте так, люди.

А если система поднимается 20 секунд, логично начать урезать осетра с самых жирных и тормозных вещей и это очень врядли чтение этого конфига. Это именно тот случай когда 20% работы даст 80% результата. Сам по себе старт 20 секунд - то еще безобразие. У вас что за железо и что там 20 секунд происходит?