Критическое время выполнения, операция чтения CSV-файлов в C - PullRequest
0 голосов
/ 09 февраля 2011

Есть ли способ кодировать быстрый и эффективный способ чтения файлов CSV?

Время выполнения является здесь критической метрикой.

Один ресурс в Интернете сосредоточен на использовании операций с двоичными файлами для массового чтения. Но я уверен, если это будет полезно при чтении файлов CSV

Есть и другие методы, например, Роберт Гэмбл, написавший код SourceForge. Есть ли способ написать его с помощью нативных функций?

Редактировать: Давайте разберем весь вопрос яснее и лучше:

  1. Существует ли эффективный (критический для времени выполнения) способ чтения файлов в C? (в данном случае файл CSV длиной в миллион строк)

  2. Есть ли быстрый эффективный способ анализа файла CSV?

Ответы [ 4 ]

1 голос
/ 09 февраля 2011

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

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

Если вы разрабатываете под Unix, вы можете попробовать это бесплатно, вообще не прибегая к дополнительному коду, получая выгоду от передачи и вывода CSV через gzip -c и gunzip -c. Просто попробуйте - для меня это ускорилось в десятки раз.

1 голос
/ 09 февраля 2011

Не существует единого способа чтения и анализа файлов любого типа, которые бывают самыми быстрыми за все время.Однако вы можете захотеть построить грамматику Ragel для CSV;те, как правило, довольно быстро.Вы можете адаптировать его к вашему конкретному типу CSV (через запятую, ;, только цифры и т. Д.) И, возможно, пропустить любые данные, которые вы не собираетесь использовать.У меня был хороший опыт работы с парсерами SQL для конкретных наборов данных, которые могли бы пропустить большую часть своего ввода (дампы базы данных).

Хорошее чтение может быть массовым чтением, но вы должны оценить реальные данные, будь тодействительно быстрее, чем stdio -буферинг.Использование двоичного ввода-вывода может немного ускорить работу в Windows, но тогда вам нужно обрабатывать переводы строк где-то еще.

0 голосов
/ 09 февраля 2011

Лучшее, на что вы можете надеяться - это переносить большие блоки текста в память (или «карту памяти» в файл) и обрабатывать текст в памяти.

Суть эффективности в том, что текстовые строки являются записями переменной длины. Обычно текст читается, пока не будет найден конец строки терминатора. В общем, это означает чтение символа и проверку на eol . Многие платформы и библиотеки пытаются сделать это более эффективным путем чтения блоков данных и поиска данных по eol .

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

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

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

Таким образом, записи и поля переменной длины по своей природе не являются самой эффективной структурой данных. Время тратится на поиск терминальных символов. Записи фиксированной длины и поля фиксированной длины более эффективны, поскольку не требуют поиска.

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

0 голосов
/ 09 февраля 2011

Установите входной буфер на гораздо больший размер, чем по умолчанию, используя setvbuf.Это единственное, что вы можете сделать в C для увеличения скорости чтения.Также проведите некоторые временные тесты, потому что будет происходить снижение доходности, после которого нет смысла увеличивать размер буфера.

Вне C вы можете начать, поместив этот .CSV на SSD-накопитель, или сохранитеэто на сжатой файловой системе.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...