Perl или C быстрее при разборе?

Question

У меня есть несколько очень больших файлов журналов, и мне нужно их проанализировать. Простота реализации, очевидно, указывает мне на Perl и регулярное выражение (в котором я еще новичок) Но как насчет скорости? Будет ли быстрее реализовать его в C? Каждый файл журнала имеет порядок 2 ГБ.

Answer 1

Я очень сомневаюсь, что C будет быстрее, чем Perl, если вы не должны были вручную скомпилировать RE.

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

Но я бы никогда не советовал это никому, кому раньше не приходилось писать компиляторы или парсеры без использования lex, yacc, bison или других подобных инструментов.

Обобщенные двигатели, такие как PCRE, как правило, достаточно мощные и достаточно быстрые (в любом случае, для моих нужд, и эти потребности часто были очень требовательными).

При использовании обычного механизма RE он должен иметь возможность обрабатывать все виды случаев, независимо от того, написано ли оно на C или Perl. Когда вы думаете о том, что быстрее, вам нужно сравнить только то, в чем написаны движки RE для обоих случаев (подсказка: движок Perl RE не написан на Perl).

Они оба написаны на C, поэтому вы должны найти очень мало различий с точки зрения скорости сопоставления.

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

Answer 2

• Наивно написанный синтаксический анализатор на основе регулярных выражений Perl будет быстрее, чем наивно написанный синтаксический анализатор, основанный на регулярных выражениях C.
• Хорошо написанный синтаксический анализатор на основе регулярных выражений Perl будет значительно * на 1005 * быстрее, чем наивно написанный синтаксический анализатор на основе регулярных выражений C.
• Хорошо написанный синтаксический анализатор на основе регулярных выражений C будет незначительно быстрее, чем хорошо написанный синтаксический анализатор на основе регулярных выражений Perl. (Писать также будет вдвое сложнее, а отладку - в десять раз.)

Answer 3

Perl regex matcher сильно оптимизирован. Это то место, где светит Perl, у вас не должно возникнуть проблем при работе с 2 ГБ файлом в Perl, а производительность должна быть легко сопоставима с версией C. Кстати: вы пытались искать уже готовый парсер журналов? Их много.

Answer 4

Если вы одинаково опытны в C и Perl, ответ прост:

1. Напишите это на Perl.
2. Если он слишком медленный, профилируйте его и исправьте.
3. Если он все еще слишком медленный, и проблема заключается в чрезмерном использовании ЦП или ОЗУ, попробуйте записать его в C.

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

Серьезно, реализация regex в perl очень быстрая, гибкая и хорошо протестирована. Любой код, который вы пишете, может быть быстрым и гибким, но он никогда не может быть так тщательно протестирован.

Поскольку вы новичок в Perl и regex, важно помнить, что есть ресурсы , которые могут предоставить вам отличную помощь , если вам это нужно , Есть даже несколько хороших учебников в прекрасном руководстве .

Что бы вы ни делали, не делайте этого:

for my $line ( <$log> ) {
    # parse line here.
}

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

Вместо этого используйте цикл while:

while (defined( my $line = <$log> )) {
    # parse line here.
}

Answer 5

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

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

Answer 6

Я предполагаю (вместо сравнения с фактическими данными Alphaneo, которых у меня нет), что обработка ввода / вывода будет ограничивающим фактором. И я ожидаю, что реализация Perl на perl с включенным usefaststdio будет соответствовать или превосходить базовую реализацию C, но будет заметно медленнее без usefaststdio. (usefaststdio был включен по умолчанию в perl 5.8 и более ранних версиях для большинства платформ и выключен по умолчанию в perl 5.10.)

Answer 7

Является ли скорость действительно фактором здесь? Вас действительно волнует, выполняется ли разбор через 5 или 10 минут?

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

Answer 8

Очевидно, что в Perl есть некоторые издержки по сравнению с C. Но эти издержки могут быть незначительными, если вы проводите большую часть времени внутри функций Perl Regex, реализованных в C.

Answer 9

В прошлом я обнаружил, что С быстрее, но не в той степени, в которой выбор был предрешен.

Задумывались ли вы об использовании универсального инструмента Log Parser, такого как Log Parser :

Log parser - мощный, универсальный инструмент, который обеспечивает универсальный запрос доступ к текстовым данным, таким как журнал файлы, файлы XML и файлы CSV, а а также ключевые источники данных на Операционная система Windows®, такая как Журнал событий, реестр, файл система и Active Directory®.

Этот сайт перечисляет несколько общих парсеров журнала.

Answer 10

Да, вы можете сделать намного более быстрый анализатор в C, если знаете, что делаете.

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