2012-02-28 2 views
2

Этот вопрос может показаться расплывчатым, извините. Есть ли у кого-нибудь опыт записи RegEx с Objective-C и Python? Мне интересно о производительности одного и другого? Что быстрее с точки зрения 1. скорости работы и потребления памяти? У меня есть приложение для Mac OS, которое всегда работает в фоновом режиме, и я хочу, чтобы мое приложение индексировало некоторые текстовые файлы, которые сохраняются, а затем сохраните результат ... Я мог бы написать метод regex в моем приложении в Obj -C, или я мог бы написать отдельное приложение, используя Perl или Python (только новичок в Python).Производительность RegEx в Objective-C vs Python

(Спасибо, я получил некоторую хорошую информацию от некоторых из вас уже Boo для тех, кто downvoted,.. Я здесь, чтобы учиться, и я мог бы иметь какие-то дурацкие время вопросы ко времени - часть сделки)

+0

«Что лучше?» для чего? Лучше всего использовать лицензию Apple? Лучшее использование памяти? Просьба представить некоторые измеримые вещи, которые вы пытаетесь оптимизировать. Затем мы можем рассказать вам, как его измерять. –

+0

Почему вы сравниваете двигатели регулярных выражений двух совершенно разных языков? Это похоже на вопрос: «Какая луна имеет более короткую орбиту, Титан или Протей?» – BoltClock

+0

В моем приложении Mac OS я буду обрабатывать некоторые тексты, и мне было интересно, будет ли делать это в Python быстрее. – janeh

ответ

2

Если вы ищете чистую скорость, ни один из этих двух будет очень хороший выбор. Для скорости выполнения вы должны выбрать Perl. Для того, как быстро вы могли бы его закодировать, либо Python, либо Perl могли бы легко побить время, чтобы записать его в Objective C, так же, как и то, и другое будет легко превзойти решение Java. Языки высокого уровня, которые занимают меньше времени для кодирования, всегда выигрывают, если все, что вы измеряете, зависит от времени по сравнению с решениями, которые занимают гораздо больше строк кода.

Что касается фактической производительности во время выполнения, регулярные выражения Perl написаны в очень жестко закодированном C и, как известно, являются самыми быстрыми и гибкими регулярными выражениями. Оптимизатор регулярных выражений делает очень много умных вещей для скомпилированной программы регулярных выражений, например, применяя оптимизацию начальной точки Aho-Corasick для поиска начала чередования trie, работающего в O (1) раз. Никто этого не делает. Черт возьми, я не думаю, что кто-либо другой, кроме Perl, даже потрудился оптимизировать чередование в попытках, что делает вас от O (n) до O (1), потому что компилятор потратил больше времени на то, чтобы сделать что-то умное, чтобы интерпретатор работает намного быстрее. Регулярные выражения также предлагают существенные улучшения в отладке и профилировании. Они также более гибкие, чем Python, но одной только отладки достаточно, чтобы опрокинуть баланс.

Единственное исключение по вопросам эффективности - это определенные патологические шаблоны, которые вырождаются при работе под любым рекурсивным обратным счётом, будь то Perl, Java или Python. Те могут быть решены с использованием рекомендованной библиотеки RE2, написанной Russ Cox, в качестве плагина замены. I знаю он доступен как прозрачный механизм регулярных выражений для Perl, и я уверен, что я помню, что он также доступен для Python.

С другой стороны, если вы действительно хотите использовать Python, но просто хочет более выразительную и надежную регулярки библиотеки, особенно один, который хорошо ведут себя на Unicode, то вы хотите использовать regex модуль Мэтью Барнетта, доступен для Python2 и Python3.Помимо соответствия требованиям стандарта tr18 для уровня 1 (это стандарт doc для регулярных выражений Unicode), он также имеет всевозможные другие умные функции, некоторые из которых полностью sui generis. Если вы ценитель регулярных выражений, это очень стоит проверить.

2

В моем приложении Mac OS я буду выполнять некоторую обработку текста, и мне было интересно, будет ли делать это в Python быстрее.

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

Если вы имеете в виду время выполнения, то вы почти наверняка выполняете преждевременную оптимизацию, если только вы не показали, что медленный код вызовет невыносимый/заметный спад в интерфейсе пользователя.

Преждевременная оптимизация - это корень всего зла. - Donald Knuth

+0

«Для почти всех программных проектов время разработки доминирует во времени исполнения как мера успеха». - Я не вписываюсь в эту группу; Я имел в виду скорость выполнения ... Чем быстрее он заканчивается, тем быстрее будет выпущена память для других процессов. – janeh

+2

@ janeh: Пожалуйста, на самом деле ** обновите ** вопрос, чтобы фактически указать, каковы ваши фактические требования. –

Смежные вопросы