regex '|' оператор по сравнению с отдельными выполнениями для каждого подвыражения

Эти две вещи дадут немного отличающиеся результаты, если не будет гарантировано, что соответствие будет соответствовать одному и только одному regex. Иначе, если что-то будет соответствовать 2, то это будет считаться дважды.

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

Кроме того, если бы это была огромная строка (больше, чем 700k) то могли бы быть усиления от выполнения одной передачи, и таким образом, фактор n меньше подкачек памяти будет необходим (к диску или кэшу CPU).

Моя ставка находится в Ваших тестах, это не действительно примечательно все же. Я интересуюсь фактическим результатом - отправьте результаты.

Чтобы понять, как модуль ре работает - компилируют _sre.c в режиме отладки (поместите #define ПОДРОБНЫЙ в 103 строки в _sre.c и перекомпилируйте Python). После этого Вы плохо видите что-то вроде этого:

>>> import re
>>> p = re.compile('(a)|(b)|(c)')
>>> p.search('a'); print '\n\n'; p.search('b')
|0xb7f9ab10|(nil)|SEARCH
prefix = (nil) 0 0
charset = (nil)
|0xb7f9ab1a|0xb7fb75f4|SEARCH
|0xb7f9ab1a|0xb7fb75f4|ENTER
allocating sre_match_context in 0 (32)
allocate/grow stack 1064
|0xb7f9ab1c|0xb7fb75f4|BRANCH
allocating sre_match_context in 32 (32)
|0xb7f9ab20|0xb7fb75f4|MARK 0
|0xb7f9ab24|0xb7fb75f4|LITERAL 97
|0xb7f9ab28|0xb7fb75f5|MARK 1
|0xb7f9ab2c|0xb7fb75f5|JUMP 20
|0xb7f9ab56|0xb7fb75f5|SUCCESS
discard data from 32 (32)
looking up sre_match_context at 0
|0xb7f9ab1c|0xb7fb75f4|JUMP_BRANCH
discard data from 0 (32)
|0xb7f9ab10|0xb7fb75f5|END




|0xb7f9ab10|(nil)|SEARCH
prefix = (nil) 0 0
charset = (nil)
|0xb7f9ab1a|0xb7fb7614|SEARCH
|0xb7f9ab1a|0xb7fb7614|ENTER
allocating sre_match_context in 0 (32)
allocate/grow stack 1064
|0xb7f9ab1c|0xb7fb7614|BRANCH
allocating sre_match_context in 32 (32)
|0xb7f9ab20|0xb7fb7614|MARK 0
|0xb7f9ab24|0xb7fb7614|LITERAL 97
discard data from 32 (32)
looking up sre_match_context at 0
|0xb7f9ab1c|0xb7fb7614|JUMP_BRANCH
allocating sre_match_context in 32 (32)
|0xb7f9ab32|0xb7fb7614|MARK 2
|0xb7f9ab36|0xb7fb7614|LITERAL 98
|0xb7f9ab3a|0xb7fb7615|MARK 3
|0xb7f9ab3e|0xb7fb7615|JUMP 11
|0xb7f9ab56|0xb7fb7615|SUCCESS
discard data from 32 (32)
looking up sre_match_context at 0
|0xb7f9ab2e|0xb7fb7614|JUMP_BRANCH
discard data from 0 (32)
|0xb7f9ab10|0xb7fb7615|END

>>>                                      

Я полагаю, что Ваше первое внедрение будет быстрее:

• Один из ключевых принципов для производительности Python является "логикой перемещения к уровню C" - значение, что встроенные функции (записанный в C) быстрее, чем реализации чистого Python. Так, когда цикл выполняется встроенным модулем Regex, это должно быть быстрее
• Один regex может искать несколько башмаков в одной передаче, означая, что он только должен пробежать Ваше содержание файла однажды, тогда как несколько regex должны будут считать целый файл многократно.

Я подозреваю, что regex также сделает то, что Вы пытаетесь сделать... только намного лучше :)

так "|" победил бы

Я соглашаюсь с amartynov, но я хотел добавить, что Вы также могли бы рассмотреть компиляцию regex сначала (re.compile ()), особенно во втором варианте, поскольку затем Вы могли бы сохранить некоторое время установки в цикле. Возможно, можно измерить это также, в то время как Вы находитесь на нем.

Причина я думаю выстрел того, работает, лучше то, что я предполагаю, что это полностью сделано в пространстве C, и не так много кода Python должен быть интерпретирован.

Но нетерпеливое ожидание чисел.

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

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

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