blocks|key|973119|text|使用第二个版本时，在使用正则表达式之前会对其进行编译。如果你要多次执行它，最好先编译它。如果不是在每次匹配时都编译，那么一次性编译也没问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|973120|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Regular Expressions are compiled before being used when using the second version. If you are going to executing it many times it is definatly better to compile it first. If not compiling every time you match for one off's is fine.

blocks|key|221084|text|我的理解是，这两个例子实际上是等价的。唯一的区别是，在第一种方法中，您可以在其他地方重用已编译的正则表达式，而不会导致重新编译它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|221085|下面是你的参考资料：http://diveintopython3.ep.io/refactoring.html|offset|length|221086|221087|使用字符串'M‘调用编译后的模式对象的搜索函数，与使用正则表达式和字符串'M’调用re.search的效果相同。只是快得多，快得多。(实际上，搜索函数只是编译正则表达式并为您调用结果模式对象的re.search方法。)+|blockquote|221088|221089|entityMap|0|LINK|mutability|MUTABLE|url|http://diveintopython3.ep.io/refactoring.html^0|0|A|19|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@$D|U|E|V|1|W]]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|Y|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

My understanding is that those two examples are effectively equivalent. The only difference is that in the first, you can reuse the compiled regular expression elsewhere without causing it to be compiled again.

Here's a reference for you: <a href="http://diveintopython3.ep.io/refactoring.html" rel="nofollow noreferrer">http://diveintopython3.ep.io/refactoring.html</a>

<blockquote>
 Calling the compiled pattern object's search function with the string 'M' accomplishes the same thing as calling re.search with both the regular expression and the string 'M'. Only much, much faster. (In fact, the re.search function simply compiles the regular expression and calls the resulting pattern object's search method for you.) 
</blockquote>

blocks|key|221132|text|FWIW：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|221133|$+python+-m+timeit+-s+"import+re"+"re.match('hello',+'hello+world')"
100000+loops,+best+of+3:+3.82+usec+per+loop

$+python+-m+timeit+-s+"import+re;+h=re.compile('hello')"+"h.match('hello+world')"
1000000+loops,+best+of+3:+1.26+usec+per+loop|code-block|syntax|javascript|221134|因此，如果您打算经常使用相同的正则表达式，那么使用re.compile可能是值得的(尤其是对于更复杂的正则表达式)。|offset|length|style|CODE|221135|反对过早优化的标准论点是适用的，但是如果您怀疑您的正则表达式可能会成为性能瓶颈，我认为使用re.compile并不会失去太多的清晰度/直截了当。|221136|更新：|BOLD|221137|在Python3.6(我怀疑上面的计时是使用Python2.x完成的)和2018硬件(MacBook专业版)下，我现在得到以下计时：|221138|%25+python+-m+timeit+-s+"import+re"+"re.match('hello',+'hello+world')"
1000000+loops,+best+of+3:+0.661+usec+per+loop

%25+python+-m+timeit+-s+"import+re;+h=re.compile('hello')"+"h.match('hello+world')"
1000000+loops,+best+of+3:+0.285+usec+per+loop

%25+python+-m+timeit+-s+"import+re"+"h=re.compile('hello');+h.match('hello+world')"
1000000+loops,+best+of+3:+0.65+usec+per+loop

%25+python+--version
Python+3.6.5+::+Anaconda,+Inc.|221139|我还添加了一个案例(请注意最后两次运行之间的引号差异)，它表明re.match(x,+...)大致等同于re.compile(x).match(...)，即似乎不会发生编译表示的幕后缓存。|221140|entityMap^0|0|0|P|A|0|19|A|0|0|3|0|0|0|V|G|1G|O|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|10|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|11|8|@$I|12|J|13|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|14|8|@$I|15|J|16|K|L]]|9|@]|A|$]]|$1|O|3|P|5|6|7|17|8|@$I|18|J|19|K|Q]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1A|8|@]|9|@]|A|$]]|$1|T|3|U|5|D|7|1B|8|@]|9|@]|A|$E|F]]|$1|V|3|W|5|6|7|1C|8|@$I|1D|J|1E|K|L]|$I|1F|J|1G|K|L]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|Y|$]]

FWIW:

<pre><code>$ python -m timeit -s "import re" "re.match('hello', 'hello world')"
100000 loops, best of 3: 3.82 usec per loop

$ python -m timeit -s "import re; h=re.compile('hello')" "h.match('hello world')"
1000000 loops, best of 3: 1.26 usec per loop
</code></pre>

so, if you're going to be using the same regex a lot, it may be worth it to do <code>re.compile</code> (especially for more complex regexes).

The standard arguments against premature optimization apply, but I don't think you really lose much clarity/straightforwardness by using <code>re.compile</code> if you suspect that your regexps may become a performance bottleneck.

Update:

Under Python 3.6 (I suspect the above timings were done using Python 2.x) and 2018 hardware (MacBook Pro), I now get the following timings:

<pre><code>% python -m timeit -s "import re" "re.match('hello', 'hello world')"
1000000 loops, best of 3: 0.661 usec per loop

% python -m timeit -s "import re; h=re.compile('hello')" "h.match('hello world')"
1000000 loops, best of 3: 0.285 usec per loop

% python -m timeit -s "import re" "h=re.compile('hello'); h.match('hello world')"
1000000 loops, best of 3: 0.65 usec per loop

% python --version
Python 3.6.5 :: Anaconda, Inc.
</code></pre>

I also added a case (notice the quotation mark differences between the last two runs) that shows that <code>re.match(x, ...)</code> is literally [roughly] equivalent to <code>re.compile(x).match(...)</code>, i.e. no behind-the-scenes caching of the compiled representation seems to happen.

blocks|key|3439127|text|我有过运行编译正则表达式数千次与动态编译相比的丰富经验，并且没有注意到任何可察觉的差异。显然，这只是一些轶事，当然也不是反对编译的一个很好的理由，但我发现两者的区别可以忽略不计。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3439128|编辑:快速浏览一下实际的Python2.5库代码后，我发现Python会在内部编译并缓存任何时候使用的正则表达式(包括对re.match()的调用)，所以您实际上只是在编译正则表达式时进行了更改，而不应该节省太多时间--只节省了检查缓存(在内部dict类型上查找键)所需的时间。|offset|length|style|CODE|3439129|来自模块re.py+(注释是我的)：|3439130|def+match(pattern,+string,+flags=0):
++++return+_compile(pattern,+flags).match(string)

def+_compile(*key):

++++#+Does+cache+check+at+top+of+function
++++cachekey+=+(type(key[0]),)+%2B+key
++++p+=+_cache.get(cachekey)
++++if+p+is+not+None:+return+p

++++#+...
++++#+Does+actual+compilation+on+cache+miss
++++#+...

++++#+Caches+compiled+regex
++++if+len(_cache)+>=+_MAXCACHE:
++++++++_cache.clear()
++++_cache[cachekey]+=+p
++++return+p|code-block|syntax|javascript|3439131|我仍然经常预编译正则表达式，但只是为了将它们绑定到一个好的、可重用的名称，而不是为了任何预期的性能提升。|3439132|entityMap^0|0|1O|A|3E|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]|$D|W|E|X|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

I've had a lot of experience running a compiled regex 1000s of times versus compiling on-the-fly, and have not noticed any perceivable difference. Obviously, this is anecdotal, and certainly not a great argument against compiling, but I've found the difference to be negligible.

EDIT:
After a quick glance at the actual Python 2.5 library code, I see that Python internally compiles AND CACHES regexes whenever you use them anyway (including calls to <code>re.match()</code>), so you're really only changing WHEN the regex gets compiled, and shouldn't be saving much time at all - only the time it takes to check the cache (a key lookup on an internal <code>dict</code> type).

From module re.py (comments are mine):

<pre><code>def match(pattern, string, flags=0):
 return _compile(pattern, flags).match(string)

def _compile(*key):

 # Does cache check at top of function
 cachekey = (type(key[0]),) + key
 p = _cache.get(cachekey)
 if p is not None: return p

 # ...
 # Does actual compilation on cache miss
 # ...

 # Caches compiled regex
 if len(_cache) &gt;= _MAXCACHE:
 _cache.clear()
 _cache[cachekey] = p
 return p
</code></pre>

I still often pre-compile regular expressions, but only to bind them to a nice, reusable name, not for any expected performance gain.

blocks|key|3439178|text|这是一个好问题。你经常看到人们无缘无故地使用re.compile。它降低了可读性。但确实有很多时候会调用预编译表达式。比如当你在一个循环中重复使用它的时候。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3439179|它就像一切关于编程的东西(实际上是生活中的一切)。运用常识。|3439180|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

This is a good question. You often see people use re.compile without reason. It lessens readability. But sure there are lots of times when pre-compiling the expression is called for. Like when you use it repeated times in a loop or some such.

It's like everything about programming (everything in life actually). Apply common sense.

blocks|key|4286122|text|对我来说，re.compile最大的好处是能够将正则表达式的定义与使用分开。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4286123|即使是像0%7C[1-9][0-9]*这样的简单表达式(以10为基数的整数，没有前导零)也可能非常复杂，以至于您不需要重新键入它，检查是否有任何拼写错误，然后在开始调试时必须重新检查是否有拼写错误。此外，使用诸如num或num_b10之类的变量名比使用0%7C[1-9][0-9]*更好。|4286124|当然，也可以存储字符串并将其传递给re.match；但是，这样做的可读性较差：|4286125|num+=+"..."
#+then,+much+later:
m+=+re.match(num,+input)|code-block|syntax|javascript|4286126|与编译相比：|4286127|num+=+re.compile("...")
#+then,+much+later:
m+=+num.match(input)|4286128|虽然它相当接近，但当重复使用时，第二行的最后一行感觉更自然和更简单。|4286129|entityMap^0|5|A|0|4|D|3G|D|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|14|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|15|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|16|8|@]|D|@]|E|$]]|$1|Q|3|R|5|L|7|17|8|@]|D|@]|E|$M|N]]|$1|S|3|T|5|6|7|18|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|V|$]]

For me, the biggest benefit to <code>re.compile</code> is being able to separate definition of the regex from its use.

Even a simple expression such as <code>0|[1-9][0-9]*</code> (integer in base 10 without leading zeros) can be complex enough that you'd rather not have to retype it, check if you made any typos, and later have to recheck if there are typos when you start debugging. Plus, it's nicer to use a variable name such as num or num_b10 than <code>0|[1-9][0-9]*</code>.

It's certainly possible to store strings and pass them to re.match; however, that's less readable:

<pre><code>num = "..."
# then, much later:
m = re.match(num, input)
</code></pre>

Versus compiling:

<pre><code>num = re.compile("...")
# then, much later:
m = num.match(input)
</code></pre>

Though it is fairly close, the last line of the second feels more natural and simpler when used repeatedly.

blocks|key|221289|text|有趣的是，编译对我来说确实更有效(+Win+XP上的Python+2.5.2+)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|221290|import+re
import+time

rgx+=+re.compile('(\w%2B)\s%2B[0-9_]?\s%2B\w*')
str+=+"average++++2+never"
a+=+0

t+=+time.time()

for+i+in+xrange(1000000):
++++if+re.match('(\w%2B)\s%2B[0-9_]?\s%2B\w*',+str):
++++#~+if+rgx.match(str):
++++++++a+%2B=+1

print+time.time()+-+t|code-block|syntax|javascript|221291|按原样运行上面的代码一次，然后用另一种方式注释两行if代码，编译后的正则表达式的速度是原来的两倍|offset|length|style|CODE|221292|entityMap^0|0|0|P|2|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Interestingly, compiling does prove more efficient for me (Python 2.5.2 on Win XP):

<pre><code>import re
import time

rgx = re.compile('(\w+)\s+[0-9_]?\s+\w*')
str = "average 2 never"
a = 0

t = time.time()

for i in xrange(1000000):
 if re.match('(\w+)\s+[0-9_]?\s+\w*', str):
 #~ if rgx.match(str):
 a += 1

print time.time() - t
</code></pre>

Running the above code once as is, and once with the two <code>if</code> lines commented the other way around, the compiled regex is twice as fast

blocks|key|3439296|text|一般来说，我发现在编译模式时使用标志(至少更容易记住如何使用)更容易，比如re.I，而不是使用内联标志。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3439297|>>>+foo_pat+=+re.compile('foo',re.I)
>>>+foo_pat.findall('some+string+FoO+bar')
['FoO']|code-block|syntax|javascript|3439298|vs|3439299|>>>+re.findall('(?i)foo','some+string+FoO+bar')
['FoO']|3439300|entityMap^0|11|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|V|8|@]|D|@]|E|$I|J]]|$1|O|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|P|$]]

In general, I find it is easier to use flags (at least easier to remember how), like <code>re.I</code> when compiling patterns than to use flags inline.

<pre><code>&gt;&gt;&gt; foo_pat = re.compile('foo',re.I)
&gt;&gt;&gt; foo_pat.findall('some string FoO bar')
['FoO']
</code></pre>

vs 

<pre><code>&gt;&gt;&gt; re.findall('(?i)foo','some string FoO bar')
['FoO']
</code></pre>

blocks|key|978697|text|(几个月后)很容易在re.match周围添加自己的缓存，或者其他任何东西--|type|unstyled|depth|inlineStyleRanges|entityRanges|data|978698|"""+Re.py:+Re.match+=+re.match+%2B+cache++
++++efficiency:+re.py+does+this+already+(but+what's+_MAXCACHE+?)
++++readability,+inline+/+separate:+matter+of+taste
"""

import+re

cache+=+{}
_re_type+=+type(+re.compile(+""+))

def+match(+pattern,+str,+*opt+):
++++"""+Re.match+=+re.match+%2B+cache+re.compile(+pattern+)+
++++"""
++++if+type(pattern)+==+_re_type:
++++++++cpat+=+pattern
++++elif+pattern+in+cache:
++++++++cpat+=+cache[pattern]
++++else:
++++++++cpat+=+cache[pattern]+=+re.compile(+pattern,+*opt+)
++++return+cpat.match(+str+)

#+def+search+...|code-block|syntax|javascript|978699|如果:+cachehint(+size=+)，cacheinfo()+->大小，命中，清除...|978700|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

(months later) it's easy to add your own cache around re.match,
or anything else for that matter --

<pre><code>""" Re.py: Re.match = re.match + cache 
 efficiency: re.py does this already (but what's _MAXCACHE ?)
 readability, inline / separate: matter of taste
"""

import re

cache = {}
_re_type = type( re.compile( "" ))

def match( pattern, str, *opt ):
 """ Re.match = re.match + cache re.compile( pattern ) 
 """
 if type(pattern) == _re_type:
 cpat = pattern
 elif pattern in cache:
 cpat = cache[pattern]
 else:
 cpat = cache[pattern] = re.compile( pattern, *opt )
 return cpat.match( str )

# def search ...
</code></pre>

A wibni, wouldn't it be nice if: cachehint( size= ), cacheinfo() -> size, hits, nclear ...

blocks|key|221429|text|在偶然发现这里的讨论之前，我运行了这个测试。然而，在运行了它之后，我想我至少应该发布我的结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|221430|我偷走了Jeff+Friedl的“精通正则表达式”中的例子，并把它写得很糟糕。这是在一台运行OSX+10.6+(2+2Ghz英特尔酷睿2双核，4+4GB内存)的macbook上。Python版本为2.6.1。|221431|Run+1-使用re.compile|offset|length|style|BOLD|221432|import+re+
import+time+
import+fpformat
Regex1+=+re.compile('%5E(a%7Cb%7Cc%7Cd%7Ce%7Cf%7Cg)%2B$')+
Regex2+=+re.compile('%5E[a-g]%2B$')
TimesToDo+=+1000
TestString+=+""+
for+i+in+range(1000):
++++TestString+%2B=+"abababdedfg"
StartTime+=+time.time()+
for+i+in+range(TimesToDo):
++++Regex1.search(TestString)+
Seconds+=+time.time()+-+StartTime+
print+"Alternation+takes+"+%2B+fpformat.fix(Seconds,3)+%2B+"+seconds"

StartTime+=+time.time()+
for+i+in+range(TimesToDo):
++++Regex2.search(TestString)+
Seconds+=+time.time()+-+StartTime+
print+"Character+Class+takes+"+%2B+fpformat.fix(Seconds,3)+%2B+"+seconds"

Alternation+takes+2.299+seconds
Character+Class+takes+0.107+seconds|code-block|syntax|javascript|221433|Run+2-不使用re.compile|221434|import+re+
import+time+
import+fpformat

TimesToDo+=+1000
TestString+=+""+
for+i+in+range(1000):
++++TestString+%2B=+"abababdedfg"
StartTime+=+time.time()+
for+i+in+range(TimesToDo):
++++re.search('%5E(a%7Cb%7Cc%7Cd%7Ce%7Cf%7Cg)%2B$',TestString)+
Seconds+=+time.time()+-+StartTime+
print+"Alternation+takes+"+%2B+fpformat.fix(Seconds,3)+%2B+"+seconds"

StartTime+=+time.time()+
for+i+in+range(TimesToDo):
++++re.search('%5E[a-g]%2B$',TestString)+
Seconds+=+time.time()+-+StartTime+
print+"Character+Class+takes+"+%2B+fpformat.fix(Seconds,3)+%2B+"+seconds"

Alternation+takes+2.508+seconds
Character+Class+takes+0.109+seconds|221435|entityMap^0|0|0|0|I|0|0|0|J|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@$F|X|G|Y|H|I]]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|10|8|@$F|11|G|12|H|I]]|9|@]|A|$]]|$1|Q|3|R|5|L|7|13|8|@]|9|@]|A|$M|N]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

I ran this test before stumbling upon the discussion here. However, having run it I thought I'd at least post my results.

I stole and bastardized the example in Jeff Friedl's "Mastering Regular Expressions". This is on a macbook running OSX 10.6 (2Ghz intel core 2 duo, 4GB ram). Python version is 2.6.1.

Run 1 - using re.compile

<pre><code>import re 
import time 
import fpformat
Regex1 = re.compile('^(a|b|c|d|e|f|g)+$') 
Regex2 = re.compile('^[a-g]+$')
TimesToDo = 1000
TestString = "" 
for i in range(1000):
 TestString += "abababdedfg"
StartTime = time.time() 
for i in range(TimesToDo):
 Regex1.search(TestString) 
Seconds = time.time() - StartTime 
print "Alternation takes " + fpformat.fix(Seconds,3) + " seconds"

StartTime = time.time() 
for i in range(TimesToDo):
 Regex2.search(TestString) 
Seconds = time.time() - StartTime 
print "Character Class takes " + fpformat.fix(Seconds,3) + " seconds"

Alternation takes 2.299 seconds
Character Class takes 0.107 seconds
</code></pre>

Run 2 - Not using re.compile

<pre><code>import re 
import time 
import fpformat

TimesToDo = 1000
TestString = "" 
for i in range(1000):
 TestString += "abababdedfg"
StartTime = time.time() 
for i in range(TimesToDo):
 re.search('^(a|b|c|d|e|f|g)+$',TestString) 
Seconds = time.time() - StartTime 
print "Alternation takes " + fpformat.fix(Seconds,3) + " seconds"

StartTime = time.time() 
for i in range(TimesToDo):
 re.search('^[a-g]+$',TestString) 
Seconds = time.time() - StartTime 
print "Character Class takes " + fpformat.fix(Seconds,3) + " seconds"

Alternation takes 2.508 seconds
Character Class takes 0.109 seconds
</code></pre>

blocks|key|973334|text|我自己也试过了。对于从字符串中解析出一个数字并对其求和的简单情况，使用编译的正则表达式对象的速度大约是使用re方法的两倍。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|973335|正如其他人所指出的，re方法(包括re.compile)在先前编译的表达式的缓存中查找正则表达式字符串。因此，在正常情况下，使用re方法的额外开销就是缓存查找的开销。|973336|但是，对code的检查显示，缓存被限制为100个表达式。这就引出了一个问题，溢出缓存有多痛苦？该代码包含一个到正则表达式编译器re.sre_compile.compile的内部接口。如果我们调用它，我们就会绕过缓存。事实证明，对于一个基本的正则表达式，比如r'\w%2B\s%2B([0-9_]%2B)\s%2B\w*'，它的速度要慢两个数量级。|973337|这是我的测试：|973338|#!/usr/bin/env+python
import+re
import+time

def+timed(func):
++++def+wrapper(*args):
++++++++t+=+time.time()
++++++++result+=+func(*args)
++++++++t+=+time.time()+-+t
++++++++print+'%25s+took+%25.3f+seconds.'+%25+(func.func_name,+t)
++++++++return+result
++++return+wrapper

regularExpression+=+r'\w%2B\s%2B([0-9_]%2B)\s%2B\w*'
testString+=+"average++++2+never"

@timed
def+noncompiled():
++++a+=+0
++++for+x+in+xrange(1000000):
++++++++m+=+re.match(regularExpression,+testString)
++++++++a+%2B=+int(m.group(1))
++++return+a

@timed
def+compiled():
++++a+=+0
++++rgx+=+re.compile(regularExpression)
++++for+x+in+xrange(1000000):
++++++++m+=+rgx.match(testString)
++++++++a+%2B=+int(m.group(1))
++++return+a

@timed
def+reallyCompiled():
++++a+=+0
++++rgx+=+re.sre_compile.compile(regularExpression)
++++for+x+in+xrange(1000000):
++++++++m+=+rgx.match(testString)
++++++++a+%2B=+int(m.group(1))
++++return+a


@timed
def+compiledInLoop():
++++a+=+0
++++for+x+in+xrange(1000000):
++++++++rgx+=+re.compile(regularExpression)
++++++++m+=+rgx.match(testString)
++++++++a+%2B=+int(m.group(1))
++++return+a

@timed
def+reallyCompiledInLoop():
++++a+=+0
++++for+x+in+xrange(10000):
++++++++rgx+=+re.sre_compile.compile(regularExpression)
++++++++m+=+rgx.match(testString)
++++++++a+%2B=+int(m.group(1))
++++return+a

r1+=+noncompiled()
r2+=+compiled()
r3+=+reallyCompiled()
r4+=+compiledInLoop()
r5+=+reallyCompiledInLoop()
print+"r1+=+",+r1
print+"r2+=+",+r2
print+"r3+=+",+r3
print+"r4+=+",+r4
print+"r5+=+",+r5
</pre>
And+here+is+the+output+on+my+machine:
<pre>
$+regexTest.py+
noncompiled+took+4.555+seconds.
compiled+took+2.323+seconds.
reallyCompiled+took+2.325+seconds.
compiledInLoop+took+4.620+seconds.
reallyCompiledInLoop+took+4.074+seconds.
r1+=++2000000
r2+=++2000000
r3+=++2000000
r4+=++2000000
r5+=++20000|code-block|syntax|javascript|973339|“reallyCompiled”方法使用绕过缓存的内部接口。请注意，在每次循环迭代上编译的代码只迭代10,000次，而不是一百万次。|973340|entityMap|0|LINK|mutability|MUTABLE|url|http://www.google.com/codesearch/p?hl=en#1IKf2ZWr9OM/tools/third_party/python_26/Lib/re.py&q=lang:python%2520re.py&sa=N&cd=4&ct=rc^0|1H|2|0|A|2|H|A|1S|2|0|1R|M|3K|O|4|4|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|13|8|@$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1A|8|@$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]]|D|@$9|1F|A|1G|1|1H]]|E|$]]|$1|J|3|K|5|6|7|1I|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|1J|8|@]|D|@]|E|$O|P]]|$1|Q|3|R|5|6|7|1K|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1L|8|@]|D|@]|E|$]]]|T|$U|$5|V|W|X|E|$Y|Z]]]]

I just tried this myself. For the simple case of parsing a number out of a string and summing it, using a compiled regular expression object is about twice as fast as using the <code>re</code> methods.

As others have pointed out, the <code>re</code> methods (including <code>re.compile</code>) look up the regular expression string in a cache of previously compiled expressions. Therefore, in the normal case, the extra cost of using the <code>re</code> methods is simply the cost of the cache lookup.

However, examination of the <a href="http://www.google.com/codesearch/p?hl=en#1IKf2ZWr9OM/tools/third_party/python_26/Lib/re.py&amp;q=lang:python%20re.py&amp;sa=N&amp;cd=4&amp;ct=rc" rel="noreferrer">code</a>, shows the cache is limited to 100 expressions. This begs the question, how painful is it to overflow the cache? The code contains an internal interface to the regular expression compiler, <code>re.sre_compile.compile</code>. If we call it, we bypass the cache. It turns out to be about two orders of magnitude slower for a basic regular expression, such as <code>r'\w+\s+([0-9_]+)\s+\w*'</code>.

Here's my test:

<pre><code>#!/usr/bin/env python
import re
import time

def timed(func):
 def wrapper(*args):
 t = time.time()
 result = func(*args)
 t = time.time() - t
 print '%s took %.3f seconds.' % (func.func_name, t)
 return result
 return wrapper

regularExpression = r'\w+\s+([0-9_]+)\s+\w*'
testString = "average 2 never"

@timed
def noncompiled():
 a = 0
 for x in xrange(1000000):
 m = re.match(regularExpression, testString)
 a += int(m.group(1))
 return a

@timed
def compiled():
 a = 0
 rgx = re.compile(regularExpression)
 for x in xrange(1000000):
 m = rgx.match(testString)
 a += int(m.group(1))
 return a

@timed
def reallyCompiled():
 a = 0
 rgx = re.sre_compile.compile(regularExpression)
 for x in xrange(1000000):
 m = rgx.match(testString)
 a += int(m.group(1))
 return a


@timed
def compiledInLoop():
 a = 0
 for x in xrange(1000000):
 rgx = re.compile(regularExpression)
 m = rgx.match(testString)
 a += int(m.group(1))
 return a

@timed
def reallyCompiledInLoop():
 a = 0
 for x in xrange(10000):
 rgx = re.sre_compile.compile(regularExpression)
 m = rgx.match(testString)
 a += int(m.group(1))
 return a

r1 = noncompiled()
r2 = compiled()
r3 = reallyCompiled()
r4 = compiledInLoop()
r5 = reallyCompiledInLoop()
print "r1 = ", r1
print "r2 = ", r2
print "r3 = ", r3
print "r4 = ", r4
print "r5 = ", r5
&lt;/pre&gt;
And here is the output on my machine:
&lt;pre&gt;
$ regexTest.py 
noncompiled took 4.555 seconds.
compiled took 2.323 seconds.
reallyCompiled took 2.325 seconds.
compiledInLoop took 4.620 seconds.
reallyCompiledInLoop took 4.074 seconds.
r1 = 2000000
r2 = 2000000
r3 = 2000000
r4 = 2000000
r5 = 20000
</code></pre>

The 'reallyCompiled' methods use the internal interface, which bypasses the cache. Note the one that compiles on each loop iteration is only iterated 10,000 times, not one million.

blocks|key|973375|text|我想说的是，预编译在概念上和“识字”(如“识字编程”)上都是有利的。看一下下面的代码片段：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|973376|from+re+import+compile+as+_Re

class+TYPO:

++def+text_has_foobar(+self,+text+):
++++return+self._text_has_foobar_re_search(+text+)+is+not+None
++_text_has_foobar_re_search+=+_Re(+r"""(?i)foobar"""+).search

TYPO+=+TYPO()|code-block|syntax|javascript|973377|在你的应用程序中，你可以这样写：|973378|from+TYPO+import+TYPO
print(+TYPO.text_has_foobar(+'FOObar+)+)|973379|就功能而言，这几乎是最简单的。因为这个示例非常简短，所以我将在一行中获取_text_has_foobar_re_search的方法合并在一起。这段代码的缺点是，无论TYPO库对象的生命周期是什么，它都会占用少量内存；优点是，在执行foobar搜索时，只需两次函数调用和两次类字典查找。re缓存了多少正则表达式以及该缓存的开销在这里无关紧要。|offset|length|style|CODE|973380|将其与更常见的风格进行比较，如下所示：|973381|import+re

class+Typo:

++def+text_has_foobar(+self,+text+):
++++return+re.compile(+r"""(?i)foobar"""+).search(+text+)+is+not+None|973382|在应用程序中：|973383|typo+=+Typo()
print(+typo.text_has_foobar(+'FOObar+)+)|973384|我坦率地承认，我的风格在python中是非常不寻常的，甚至可能是有争议的。然而，在这个更接近python使用方式的示例中，为了进行单个匹配，我们必须实例化一个对象，执行三次实例字典查找，并执行三次函数调用；此外，当使用超过100个正则表达式时，我们可能会遇到re缓存问题。此外，正则表达式被隐藏在方法体中，这在大多数情况下并不是一个好主意。|973385|可以说，度量的每个子集-有针对性的、带别名的导入语句；适用的带别名的方法；减少函数调用和对象字典查找-可以帮助降低计算和概念复杂性。|973386|entityMap^0|0|0|0|0|10|Q|2A|4|3Y|2|0|0|0|0|0|3L|2|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|16|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|18|8|@$M|19|N|1A|O|P]|$M|1B|N|1C|O|P]|$M|1D|N|1E|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1F|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|1G|8|@]|9|@]|A|$E|F]]|$1|U|3|V|5|6|7|1H|8|@]|9|@]|A|$]]|$1|W|3|X|5|D|7|1I|8|@]|9|@]|A|$E|F]]|$1|Y|3|Z|5|6|7|1J|8|@$M|1K|N|1L|O|P]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1M|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|13|$]]

i'd like to motivate that pre-compiling is both conceptually and 'literately' (as in 'literate programming') advantageous. have a look at this code snippet:

<pre><code>from re import compile as _Re

class TYPO:

 def text_has_foobar( self, text ):
 return self._text_has_foobar_re_search( text ) is not None
 _text_has_foobar_re_search = _Re( r"""(?i)foobar""" ).search

TYPO = TYPO()
</code></pre>

in your application, you'd write:

<pre><code>from TYPO import TYPO
print( TYPO.text_has_foobar( 'FOObar ) )
</code></pre>

this is about as simple in terms of functionality as it can get. because this is example is so short, i conflated the way to get <code>_text_has_foobar_re_search</code> all in one line. the disadvantage of this code is that it occupies a little memory for whatever the lifetime of the <code>TYPO</code> library object is; the advantage is that when doing a foobar search, you'll get away with two function calls and two class dictionary lookups. how many regexes are cached by <code>re</code> and the overhead of that cache are irrelevant here. 

compare this with the more usual style, below:

<pre><code>import re

class Typo:

 def text_has_foobar( self, text ):
 return re.compile( r"""(?i)foobar""" ).search( text ) is not None
</code></pre>

In the application:

<pre><code>typo = Typo()
print( typo.text_has_foobar( 'FOObar ) )
</code></pre>

I readily admit that my style is highly unusual for python, maybe even debatable. however, in the example that more closely matches how python is mostly used, in order to do a single match, we must instantiate an object, do three instance dictionary lookups, and perform three function calls; additionally, we might get into <code>re</code> caching troubles when using more than 100 regexes. also, the regular expression gets hidden inside the method body, which most of the time is not such a good idea. 

be it said that every subset of measures---targeted, aliased import statements; aliased methods where applicable; reduction of function calls and object dictionary lookups---can help reduce computational and conceptual complexity.

blocks|key|221583|text|下面是一个简单的测试用例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|221584|~$+for+x+in+1+10+100+1000+10000+100000+1000000;+do+python+-m+timeit+-n+$x+-s+'import+re'+'re.match("[0-9]{3}-[0-9]{3}-[0-9]{4}",+"123-123-1234")';+done
1+loops,+best+of+3:+3.1+usec+per+loop
10+loops,+best+of+3:+2.41+usec+per+loop
100+loops,+best+of+3:+2.24+usec+per+loop
1000+loops,+best+of+3:+2.21+usec+per+loop
10000+loops,+best+of+3:+2.23+usec+per+loop
100000+loops,+best+of+3:+2.24+usec+per+loop
1000000+loops,+best+of+3:+2.31+usec+per+loop|code-block|syntax|javascript|221585|使用re.compile：|221586|~$+for+x+in+1+10+100+1000+10000+100000+1000000;+do+python+-m+timeit+-n+$x+-s+'import+re'+'r+=+re.compile("[0-9]{3}-[0-9]{3}-[0-9]{4}")'+'r.match("123-123-1234")';+done
1+loops,+best+of+3:+1.91+usec+per+loop
10+loops,+best+of+3:+0.691+usec+per+loop
100+loops,+best+of+3:+0.701+usec+per+loop
1000+loops,+best+of+3:+0.684+usec+per+loop
10000+loops,+best+of+3:+0.682+usec+per+loop
100000+loops,+best+of+3:+0.694+usec+per+loop
1000000+loops,+best+of+3:+0.702+usec+per+loop|221587|因此，在这种简单的情况下，即使只匹配一次，编译速度似乎也会更快。|221588|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Here's a simple test case:

<pre><code>~$ for x in 1 10 100 1000 10000 100000 1000000; do python -m timeit -n $x -s 'import re' 're.match("[0-9]{3}-[0-9]{3}-[0-9]{4}", "123-123-1234")'; done
1 loops, best of 3: 3.1 usec per loop
10 loops, best of 3: 2.41 usec per loop
100 loops, best of 3: 2.24 usec per loop
1000 loops, best of 3: 2.21 usec per loop
10000 loops, best of 3: 2.23 usec per loop
100000 loops, best of 3: 2.24 usec per loop
1000000 loops, best of 3: 2.31 usec per loop
</code></pre>

with re.compile: 

<pre><code>~$ for x in 1 10 100 1000 10000 100000 1000000; do python -m timeit -n $x -s 'import re' 'r = re.compile("[0-9]{3}-[0-9]{3}-[0-9]{4}")' 'r.match("123-123-1234")'; done
1 loops, best of 3: 1.91 usec per loop
10 loops, best of 3: 0.691 usec per loop
100 loops, best of 3: 0.701 usec per loop
1000 loops, best of 3: 0.684 usec per loop
10000 loops, best of 3: 0.682 usec per loop
100000 loops, best of 3: 0.694 usec per loop
1000000 loops, best of 3: 0.702 usec per loop
</code></pre>

So, it would seem to compiling is faster with this simple case, even if you only match once.

blocks|key|4286474|text|使用给定的示例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4286475|h+=+re.compile('hello')
h.match('hello+world')|code-block|syntax|javascript|4286476|上例中的match方法与下面使用的方法不同：|4286477|re.match('hello',+'hello+world')|4286478|re.compile()返回一个regular+expression+object，这意味着h是一个正则表达式对象。|offset|length|style|CODE|4286479|正则表达式对象有自己的方法，带有可选的pos和endpos参数：|4286480|regex.match(string[,+pos[,+endpos]])|4286481|pos|BOLD|4286482|4286483|可选的第二个参数pos在字符串中给出了一个开始搜索的索引；它缺省为0。这并不完全等同于对字符串进行分片；'%5E'模式字符在字符串的实际开头和换行符之后的位置匹配，但不一定在搜索开始的索引处匹配。|blockquote|4286484|4286485|4286486|endpos|4286487|4286488|可选参数endpos限制搜索字符串的距离；它将假定字符串的长度为endpos字符长度，因此将只搜索从pos到endpos+-+1的字符。如果endpos小于pos，则不会找到匹配项；否则，如果rx是已编译的正则表达式对象，则rx.search(string,+0,+++50)等同于rx.search(string[:50],+0)。|4286489|4286490|4286491|regex对象的search、findall和finditer方法也支持这些参数。|4286492|如您所见，re.match(pattern,+string,+flags=0)不支持它们，|4286493|它的search、findall和finditer对应项也没有。|4286494|match+object具有补充这些参数的属性：|4286495|match.pos|4286496|匹配传递给正则表达式对象的|4286497|+()或()方法的pos的值。这是RE引擎开始查找匹配的字符串的索引。|4286498|4286499|4286500|match.endpos|4286501|4286502|+()或()方法的endpos的值。这是进入字符串的索引，RE引擎不会超出该索引。|4286503|4286504|4286505|4286506|regex+object有两个独特的、可能有用的属性：|4286507|regex.groups|4286508|4286509|模式中的捕获组数量。|4286510|4286511|4286512|regex.groupindex|4286513|4286514|将(?P)定义的任何符号组名映射到组号的字典。如果模式中没有使用符号组，则字典为空。|4286515|4286516|4286517|4286518|最后，match+object具有以下属性：|4286519|match.re|4286520|搜索正则表达式对象，该对象的|4286521|+()或search()方法生成此匹配实例。|4286522|4286523|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.python.org/3.3/library/re.html?highlight=re.sub#re.compile|1|http://docs.python.org/3.3/library/re.html?highlight=re.sub#regular-expression-objects|2|http://docs.python.org/3.3/library/re.html?highlight=re.sub#re.regex.match|3|http://docs.python.org/3.3/library/re.html?highlight=re.sub#re.match|4|http://docs.python.org/3.3/library/re.html?highlight=re.sub#match-objects|5|6^0|0|0|0|0|1A|1|0|C|0|G|P|1|0|0|0|10|0|10|2|0|0|3|0|0|1G|3|0|0|0|0|6|0|0|1I|A|34|Q|3X|P|0|0|0|0|5|Y|5|Y|3|0|0|0|C|4|0|0|9|0|0|0|0|0|0|C|0|0|0|0|0|0|0|C|5|0|0|C|0|0|0|0|0|0|G|0|0|0|0|0|0|3|C|6|0|0|8|0|0|0|0^^$0|@$1|2|3|4|5|6|7|36|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|37|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|38|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|39|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|3A|8|@$M|3B|N|3C|O|P]]|9|@$M|3D|N|3E|1|3F]|$M|3G|N|3H|1|3I]]|A|$]]|$1|Q|3|R|5|6|7|3J|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|3K|8|@$M|3L|N|3M|O|P]]|9|@$M|3N|N|3O|1|3P]]|A|$]]|$1|U|3|V|5|6|7|3Q|8|@$M|3R|N|3S|O|W]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|3T|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|10|7|3U|8|@$M|3V|N|3W|O|P]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|3X|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|3Y|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|3Z|8|@$M|40|N|41|O|W]]|9|@]|A|$]]|$1|15|3|-4|5|6|7|42|8|@]|9|@]|A|$]]|$1|16|3|17|5|10|7|43|8|@$M|44|N|45|O|P]|$M|46|N|47|O|P]|$M|48|N|49|O|P]]|9|@]|A|$]]|$1|18|3|-4|5|6|7|4A|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|4B|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|4C|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|4D|8|@$M|4E|N|4F|O|P]]|9|@$M|4G|N|4H|1|4I]]|A|$]]|$1|1E|3|1F|5|6|7|4J|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|4K|8|@]|9|@$M|4L|N|4M|1|4N]]|A|$]]|$1|1I|3|1J|5|6|7|4O|8|@$M|4P|N|4Q|O|W]]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|4R|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|10|7|4S|8|@]|9|@]|A|$]]|$1|1O|3|-4|5|6|7|4T|8|@]|9|@]|A|$]]|$1|1P|3|-4|5|6|7|4U|8|@]|9|@]|A|$]]|$1|1Q|3|1R|5|6|7|4V|8|@$M|4W|N|4X|O|W]]|9|@]|A|$]]|$1|1S|3|1L|5|6|7|4Y|8|@]|9|@]|A|$]]|$1|1T|3|1U|5|10|7|4Z|8|@]|9|@]|A|$]]|$1|1V|3|-4|5|6|7|50|8|@]|9|@]|A|$]]|$1|1W|3|-4|5|6|7|51|8|@]|9|@]|A|$]]|$1|1X|3|-4|5|6|7|52|8|@]|9|@]|A|$]]|$1|1Y|3|1Z|5|6|7|53|8|@]|9|@$M|54|N|55|1|56]]|A|$]]|$1|20|3|21|5|6|7|57|8|@$M|58|N|59|O|W]]|9|@]|A|$]]|$1|22|3|-4|5|6|7|5A|8|@]|9|@]|A|$]]|$1|23|3|24|5|10|7|5B|8|@]|9|@]|A|$]]|$1|25|3|-4|5|6|7|5C|8|@]|9|@]|A|$]]|$1|26|3|-4|5|6|7|5D|8|@]|9|@]|A|$]]|$1|27|3|28|5|6|7|5E|8|@$M|5F|N|5G|O|W]]|9|@]|A|$]]|$1|29|3|-4|5|6|7|5H|8|@]|9|@]|A|$]]|$1|2A|3|2B|5|10|7|5I|8|@]|9|@]|A|$]]|$1|2C|3|-4|5|6|7|5J|8|@]|9|@]|A|$]]|$1|2D|3|-4|5|6|7|5K|8|@]|9|@]|A|$]]|$1|2E|3|-4|5|6|7|5L|8|@]|9|@]|A|$]]|$1|2F|3|2G|5|6|7|5M|8|@]|9|@$M|5N|N|5O|1|5P]]|A|$]]|$1|2H|3|2I|5|6|7|5Q|8|@$M|5R|N|5S|O|W]]|9|@]|A|$]]|$1|2J|3|2K|5|6|7|5T|8|@]|9|@]|A|$]]|$1|2L|3|2M|5|10|7|5U|8|@]|9|@]|A|$]]|$1|2N|3|-4|5|6|7|5V|8|@]|9|@]|A|$]]|$1|2O|3|-4|5|6|7|5W|8|@]|9|@]|A|$]]]|2P|$2Q|$5|2R|2S|2T|A|$2U|2V]]|2W|$5|2R|2S|2T|A|$2U|2X]]|2Y|$5|2R|2S|2T|A|$2U|2Z]]|30|$5|2R|2S|2T|A|$2U|31]]|32|$5|2R|2S|2T|A|$2U|33]]|34|$5|2R|2S|2T|A|$2U|2X]]|35|$5|2R|2S|2T|A|$2U|33]]]]

Using the given examples:

<pre><code>h = re.compile('hello')
h.match('hello world')
</code></pre>

The match method in the example above is not the same as the one used below:

<pre><code>re.match('hello', 'hello world')
</code></pre>

<a href="http://docs.python.org/3.3/library/re.html?highlight=re.sub#re.compile" rel="noreferrer">re.compile()</a> returns a <a href="http://docs.python.org/3.3/library/re.html?highlight=re.sub#regular-expression-objects" rel="noreferrer">regular expression object</a>, which means <code>h</code> is a regex object.

The regex object has its own <a href="http://docs.python.org/3.3/library/re.html?highlight=re.sub#re.regex.match" rel="noreferrer">match</a> method with the optional pos and endpos parameters:

<a href="http://docs.python.org/3.3/library/re.html?highlight=re.sub#re.regex.match" rel="noreferrer"><code>regex.match(string[, pos[, endpos]])</code></a> 

pos

<blockquote>
 The optional second parameter pos gives an index in the string where
 the search is to start; it defaults to 0. This is not completely
 equivalent to slicing the string; the <code>'^'</code> pattern character matches at
 the real beginning of the string and at positions just after a
 newline, but not necessarily at the index where the search is to
 start.
</blockquote>

endpos

<blockquote>
 The optional parameter endpos limits how far the string will be
 searched; it will be as if the string is endpos characters long, so
 only the characters from pos to <code>endpos - 1</code> will be searched for a
 match. If endpos is less than pos, no match will be found; otherwise,
 if rx is a compiled regular expression object, <code>rx.search(string, 0,
 50)</code> is equivalent to <code>rx.search(string[:50], 0)</code>.
</blockquote>

The regex object's search, findall, and finditer methods also support these parameters.

<a href="http://docs.python.org/3.3/library/re.html?highlight=re.sub#re.match" rel="noreferrer"><code>re.match(pattern, string, flags=0)</code></a> does not support them as you can see, 
nor does its search, findall, and finditer counterparts.

A <a href="http://docs.python.org/3.3/library/re.html?highlight=re.sub#match-objects" rel="noreferrer">match object</a> has attributes that complement these parameters:

match.pos

<blockquote>
 The value of pos which was passed to the search() or match() method of
 a regex object. This is the index into the string at which the RE
 engine started looking for a match.
</blockquote>

match.endpos

<blockquote>
 The value of endpos which was passed to the search() or match() method
 of a regex object. This is the index into the string beyond which the
 RE engine will not go.
</blockquote>

<hr>

A <a href="http://docs.python.org/3.3/library/re.html?highlight=re.sub#regular-expression-objects" rel="noreferrer">regex object</a> has two unique, possibly useful, attributes:

regex.groups

<blockquote>
 The number of capturing groups in the pattern.
</blockquote>

regex.groupindex

<blockquote>
 A dictionary mapping any symbolic group names defined by (?P) to
 group numbers. The dictionary is empty if no symbolic groups were used
 in the pattern.
</blockquote>

<hr>

And finally, a <a href="http://docs.python.org/3.3/library/re.html?highlight=re.sub#match-objects" rel="noreferrer">match object</a> has this attribute:

match.re

<blockquote>
 The regular expression object whose match() or search() method
 produced this match instance.
</blockquote>

blocks|key|973450|text|抛开性能差异不谈，使用re.compile和编译后的正则表达式对象进行匹配(任何与正则表达式相关的操作)可以使语义对Python运行时更加清晰。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|973451|我在调试一些简单的代码时有过一些痛苦的经历：|973452|compare+=+lambda+s,+p:+re.match(p,+s)|code-block|syntax|javascript|973453|稍后，我将在|973454|[x+for+x+in+data+if+compare(patternPhrases,+x[columnIndex])]|973455|其中，patternPhrases是包含正则表达式字符串的变量，x[columnIndex]是包含字符串的变量。|offset|length|style|CODE|973456|我遇到了麻烦，因为patternPhrases与预期的字符串不匹配！|973457|但是如果我使用re.compile表单：|973458|compare+=+lambda+s,+p:+p.match(s)|973459|然后在|973460|[x+for+x+in+data+if+compare(patternPhrases,+x[columnIndex])]|973461|Python可能会抱怨“字符串没有匹配属性”，因为在compare中通过位置参数映射，x[columnIndex]被用作正则表达式！，而实际上我的意思是|973462|compare+=+lambda+p,+s:+p.match(s)|973463|在我的例子中，使用re.compile更清楚地说明了正则表达式的目的，因为它的值对肉眼是隐藏的，因此我可以从Python运行时检查中获得更多帮助。|973464|所以我的教训是，当正则表达式不仅仅是文字字符串时，我应该使用re.compile让Python帮助我断言我的假设。|973465|entityMap^0|0|0|0|0|0|3|E|W|E|0|9|E|0|0|0|0|0|Q|7|17|E|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1E|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1F|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1G|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1H|8|@$O|1I|P|1J|Q|R]|$O|1K|P|1L|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1M|8|@$O|1N|P|1O|Q|R]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1P|8|@]|9|@]|A|$]]|$1|W|3|X|5|F|7|1Q|8|@]|9|@]|A|$G|H]]|$1|Y|3|Z|5|6|7|1R|8|@]|9|@]|A|$]]|$1|10|3|11|5|F|7|1S|8|@]|9|@]|A|$G|H]]|$1|12|3|13|5|6|7|1T|8|@$O|1U|P|1V|Q|R]|$O|1W|P|1X|Q|R]]|9|@]|A|$]]|$1|14|3|15|5|F|7|1Y|8|@]|9|@]|A|$G|H]]|$1|16|3|17|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|20|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|21|8|@]|9|@]|A|$]]]|1B|$]]

Performance difference aside, using re.compile and using the compiled regular expression object to do match (whatever regular expression related operations) makes the semantics clearer to Python run-time.

I had some painful experience of debugging some simple code:

<pre><code>compare = lambda s, p: re.match(p, s)
</code></pre>

and later I'd use compare in 

<pre><code>[x for x in data if compare(patternPhrases, x[columnIndex])]
</code></pre>

where <code>patternPhrases</code> is supposed to be a variable containing regular expression string, <code>x[columnIndex]</code> is a variable containing string.

I had trouble that <code>patternPhrases</code> did not match some expected string!

But if I used the re.compile form:

<pre><code>compare = lambda s, p: p.match(s)
</code></pre>

then in 

<pre><code>[x for x in data if compare(patternPhrases, x[columnIndex])]
</code></pre>

Python would have complained that "string does not have attribute of match", as by positional argument mapping in <code>compare</code>, <code>x[columnIndex]</code> is used as regular expression!, when I actually meant

<pre><code>compare = lambda p, s: p.match(s)
</code></pre>

In my case, using re.compile is more explicit of the purpose of regular expression, when it's value is hidden to naked eyes, thus I could get more help from Python run-time checking. 

So the moral of my lesson is that when the regular expression is not just literal string, then I should use re.compile to let Python to help me to assert my assumption.

blocks|key|4286567|text|我同意诚实的Abe的观点，即给定示例中的match(...)是不同的。它们不是一对一的比较，因此结果各不相同。为了简化我的回答，我对这些函数使用了A、B、C、D。哦，是的，我们在re.py中处理的是4个函数而不是3个。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4286568|运行这段代码：|4286569|h+=+re.compile('hello')+++++++++++++++++++#+(A)
h.match('hello+world')++++++++++++++++++++#+(B)|code-block|syntax|javascript|4286570|与运行以下代码相同：|4286571|re.match('hello',+'hello+world')++++++++++#+(C)|4286572|因为，当查看源re.py时，(A+%2B+B)意味着：|4286573|h+=+re._compile('hello')++++++++++++++++++#+(D)
h.match('hello+world')|4286574|和(C)实际上是：|4286575|re._compile('hello').match('hello+world')|4286576|因此，(C)与(B)不同。实际上，(C)在调用(D)之后调用(B)，(D)也是由(A)调用的。换句话说，就是(C)+=+(A)+%2B+(B)。因此，在循环中比较(A+%2B+B)的结果与在循环中比较(C)的结果相同。|4286577|乔治的regexTest.py为我们证明了这一点。|4286578|noncompiled+took+4.555+seconds.+++++++++++#+(C)+in+a+loop
compiledInLoop+took+4.620+seconds.++++++++#+(A+%2B+B)+in+a+loop
compiled+took+2.323+seconds.++++++++++++++#+(A)+once+%2B+(B)+in+a+loop|4286579|大家感兴趣的是，如何得到2.323秒的结果。为了确保compile(...)只被调用一次，我们需要将编译后的regex对象存储在内存中。如果我们使用一个类，我们可以存储对象并在每次调用我们的函数时重用。|4286580|class+Foo:
++++regex+=+re.compile('hello')
++++def+my_function(text)
++++++++return+regex.match(text)|4286581|如果我们没有使用class+(这是我今天的请求)，那么我无可奉告。我还在学习如何在Python中使用全局变量，我知道全局变量是一件坏事。|4286582|还有一点，我认为使用(A)+%2B+(B)方法占了上风。以下是我观察到的一些事实(如果我错了，请纠正我)：|4286583|4286584|调用A一次，它将在_cache中执行一次搜索，然后执行一次sre_compile.compile()以创建正则表达式对象。调用A两次，它将执行两次搜索和一次编译(因为正则表达式对象被缓存)。|ordered-list-item|4286585|4286586|4286587|如果_cache在两者之间被刷新，那么正则表达式对象将从内存中释放，Python需要重新编译。(有人建议Python不会重新编译。)|4286588|4286589|4286590|如果我们使用(A)保留正则表达式对象，那么正则表达式对象仍然会进入_cache并以某种方式被刷新。但是我们的代码保留了一个引用，并且regex对象不会从内存中释放。这些，Python不需要重新编译。|4286591|4286592|4286593|测试编译循环与编译循环的2秒差异主要是构建密钥和搜索_cache所需的时间。这并不意味着正则表达式的编译时间。|4286594|4286595|4286596|George的真正的编译测试展示了如果每次都重新编译会发生什么:它将慢100倍(他将循环从1,000,000减少到10,000)。|4286597|4286598|以下是(A+%2B+B)比(C)更好的唯一情况：|4286599|4286600|如果我们可以在类内缓存正则表达式对象的引用。|4286601|如果我们需要重复调用(B)+(在循环内或多次)，则必须在循环外缓存对正则表达式对象的引用。|4286602|4286603|(C)足够好的情况：|4286604|4286605|我们不能缓存一个reference.|4286606|We，只是偶尔使用它一次。|4286607|总的来说，我们没有太多的正则表达式(假设编译后的|4286608|永远不会被刷新)|4286609|4286610|简单回顾一下，下面是A、B、C：|4286611|h+=+re.compile('hello')+++++++++++++++++++#+(A)
h.match('hello+world')++++++++++++++++++++#+(B)
re.match('hello',+'hello+world')++++++++++#+(C)|4286612|感谢您的阅读。|4286613|entityMap^0|K|A|2H|5|0|0|0|0|0|7|5|0|0|0|0|1I|F|0|3|C|0|0|Q|C|0|0|0|A|9|0|0|9|6|T|L|0|0|0|2|6|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2P|8|@$9|2Q|A|2R|B|C]|$9|2S|A|2T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|2U|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|2V|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|2W|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|2X|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|2Y|8|@$9|2Z|A|30|B|C]]|D|@]|E|$]]|$1|S|3|T|5|J|7|31|8|@]|D|@]|E|$K|L]]|$1|U|3|V|5|6|7|32|8|@]|D|@]|E|$]]|$1|W|3|X|5|J|7|33|8|@]|D|@]|E|$K|L]]|$1|Y|3|Z|5|6|7|34|8|@$9|35|A|36|B|C]]|D|@]|E|$]]|$1|10|3|11|5|6|7|37|8|@$9|38|A|39|B|C]]|D|@]|E|$]]|$1|12|3|13|5|J|7|3A|8|@]|D|@]|E|$K|L]]|$1|14|3|15|5|6|7|3B|8|@$9|3C|A|3D|B|C]]|D|@]|E|$]]|$1|16|3|17|5|J|7|3E|8|@]|D|@]|E|$K|L]]|$1|18|3|19|5|6|7|3F|8|@]|D|@]|E|$]]|$1|1A|3|1B|5|6|7|3G|8|@$9|3H|A|3I|B|C]]|D|@]|E|$]]|$1|1C|3|-4|5|6|7|3J|8|@]|D|@]|E|$]]|$1|1D|3|1E|5|1F|7|3K|8|@$9|3L|A|3M|B|C]|$9|3N|A|3O|B|C]]|D|@]|E|$]]|$1|1G|3|-4|5|6|7|3P|8|@]|D|@]|E|$]]|$1|1H|3|-4|5|6|7|3Q|8|@]|D|@]|E|$]]|$1|1I|3|1J|5|1F|7|3R|8|@$9|3S|A|3T|B|C]]|D|@]|E|$]]|$1|1K|3|-4|5|6|7|3U|8|@]|D|@]|E|$]]|$1|1L|3|-4|5|6|7|3V|8|@]|D|@]|E|$]]|$1|1M|3|1N|5|1F|7|3W|8|@]|D|@]|E|$]]|$1|1O|3|-4|5|6|7|3X|8|@]|D|@]|E|$]]|$1|1P|3|-4|5|6|7|3Y|8|@]|D|@]|E|$]]|$1|1Q|3|1R|5|1F|7|3Z|8|@]|D|@]|E|$]]|$1|1S|3|-4|5|6|7|40|8|@]|D|@]|E|$]]|$1|1T|3|-4|5|6|7|41|8|@]|D|@]|E|$]]|$1|1U|3|1V|5|1F|7|42|8|@]|D|@]|E|$]]|$1|1W|3|-4|5|6|7|43|8|@]|D|@]|E|$]]|$1|1X|3|1Y|5|6|7|44|8|@]|D|@]|E|$]]|$1|1Z|3|-4|5|6|7|45|8|@]|D|@]|E|$]]|$1|20|3|21|5|1F|7|46|8|@]|D|@]|E|$]]|$1|22|3|23|5|1F|7|47|8|@]|D|@]|E|$]]|$1|24|3|-4|5|6|7|48|8|@]|D|@]|E|$]]|$1|25|3|26|5|6|7|49|8|@]|D|@]|E|$]]|$1|27|3|-4|5|6|7|4A|8|@]|D|@]|E|$]]|$1|28|3|29|5|1F|7|4B|8|@]|D|@]|E|$]]|$1|2A|3|2B|5|1F|7|4C|8|@]|D|@]|E|$]]|$1|2C|3|2D|5|1F|7|4D|8|@]|D|@]|E|$]]|$1|2E|3|2F|5|1F|7|4E|8|@]|D|@]|E|$]]|$1|2G|3|-4|5|6|7|4F|8|@]|D|@]|E|$]]|$1|2H|3|2I|5|6|7|4G|8|@]|D|@]|E|$]]|$1|2J|3|2K|5|J|7|4H|8|@]|D|@]|E|$K|L]]|$1|2L|3|2M|5|6|7|4I|8|@]|D|@]|E|$]]|$1|2N|3|-4|5|6|7|4J|8|@]|D|@]|E|$]]]|2O|$]]

I agree with Honest Abe that the <code>match(...)</code> in the given examples are different. They are not a one-to-one comparisons and thus, outcomes are vary. To simplify my reply, I use A, B, C, D for those functions in question. Oh yes, we are dealing with 4 functions in <code>re.py</code> instead of 3.
Running this piece of code:
<pre><code>h = re.compile('hello') # (A)
h.match('hello world') # (B)
</code></pre>
is same as running this code:
<pre><code>re.match('hello', 'hello world') # (C)
</code></pre>
Because, when looked into the source <code>re.py</code>, (A + B) means:
<pre><code>h = re._compile('hello') # (D)
h.match('hello world')
</code></pre>
and (C) is actually:
<pre><code>re._compile('hello').match('hello world')
</code></pre>
So, (C) is not the same as (B). In fact, (C) calls (B) after calling (D) which is also called by (A). In other words, <code>(C) = (A) + (B)</code>. Therefore, comparing (A + B) inside a loop has the same result as (C) inside a loop.
George's <code>regexTest.py</code> proved this for us.
<pre><code>noncompiled took 4.555 seconds. # (C) in a loop
compiledInLoop took 4.620 seconds. # (A + B) in a loop
compiled took 2.323 seconds. # (A) once + (B) in a loop
</code></pre>
Everyone's interest is, how to get the result of 2.323 seconds. In order to make sure <code>compile(...)</code> only gets called once, we need to store the compiled regex object in memory. If we are using a class, we could store the object and reuse when every time our function gets called.
<pre><code>class Foo:
 regex = re.compile('hello')
 def my_function(text)
 return regex.match(text)
</code></pre>
If we are not using class (which is my request today), then I have no comment. I'm still learning to use a global variable in Python, and I know a global variable is a bad thing.
One more point, I believe that using <code>(A) + (B)</code> approach has an upper hand. Here are some facts as I observed (please correct me if I'm wrong):
<ol>
<li>Calls A once, it will do one search in the <code>_cache</code> followed by one <code>sre_compile.compile()</code> to create a regex object. Calls A twice, it will do two searches and one compile (because the regex object is cached).
</li>
<li>If the <code>_cache</code> gets flushed in between, then the regex object is released from memory and Python needs to compile again. (someone suggests that Python won't recompile.)
</li>
<li>If we keep the regex object by using (A), the regex object will still get into _cache and get flushed somehow. But our code keeps a reference on it and the regex object will not be released from memory. Those, Python need not to compile again.
</li>
<li>The 2 seconds difference in George's test compiled loop vs compiled is mainly the time required to build the key and search the _cache. It doesn't mean the compile time of regex.
</li>
<li>George's reallycompile test show what happens if it really re-do the compile every time: it will be 100x slower (he reduced the loop from 1,000,000 to 10,000).
</li>
</ol>
Here are the only cases that (A + B) is better than (C):
<ol>
<li>If we can cache a reference of the regex object inside a class.</li>
<li>If we need to calls (B) repeatedly (inside a loop or multiple times), we must cache the reference to the regex object outside the loop.</li>
</ol>
Case that (C) is good enough:
<ol>
<li>We cannot cache a reference.</li>
<li>We only use it once in a while.</li>
<li>In overall, we don't have too many regex (assume the compiled one never get flushed)</li>
</ol>
Just a recap, here are the A B C:
<pre><code>h = re.compile('hello') # (A)
h.match('hello world') # (B)
re.match('hello', 'hello world') # (C)
</code></pre>
Thanks for reading.

blocks|key|4286662|text|使用re.compile()还有一个额外的好处，那就是使用re.VERBOSE向我的正则模式添加注释|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4286663|pattern+=+'''
hello[+]world++++#+Some+info+on+my+pattern+logic.+[+]+to+recognize+space
'''

re.search(pattern,+'hello+world',+re.VERBOSE)|code-block|syntax|javascript|4286664|虽然这不会影响代码的运行速度，但我喜欢这样做，因为这是我注释习惯的一部分。我完全不喜欢花时间去记住我的代码背后的逻辑，当我想要进行修改的两个月后。|4286665|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

There is one addition perk of using re.compile(), in the form of adding comments to my regex patterns using re.VERBOSE

<pre><code>pattern = '''
hello[ ]world # Some info on my pattern logic. [ ] to recognize space
'''

re.search(pattern, 'hello world', re.VERBOSE)
</code></pre>

Although this does not affect the speed of running your code, I like to do it this way as it is part of my commenting habit. I throughly dislike spending time trying to remember the logic that went behind my code 2 months down the line when I want to make modifications.

blocks|key|973552|text|这个答案可能来得有点晚，但这是一个有趣的发现。如果您计划多次使用正则表达式，使用编译确实可以节省时间(文档中也提到了这一点)。下面您可以看到，当直接调用match方法时，使用已编译的正则表达式是最快的。将编译后的正则表达式传递给re.match会使其变得更慢，而传递带有patter字符串的re.match则处于中间位置。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|973553|>>>+ipr+=+r'\D%2B((([0-2][0-5]?[0-5]?)\.){3}([0-2][0-5]?[0-5]?))\D%2B'
>>>+average(*timeit.repeat("re.match(ipr,+'abcd100.10.255.255+')",+globals={'ipr':+ipr,+'re':+re}))
1.5077415757028423
>>>+ipr+=+re.compile(ipr)
>>>+average(*timeit.repeat("re.match(ipr,+'abcd100.10.255.255+')",+globals={'ipr':+ipr,+'re':+re}))
1.8324008992184038
>>>+average(*timeit.repeat("ipr.match('abcd100.10.255.255+')",+globals={'ipr':+ipr,+'re':+re}))
0.9187896518778871|code-block|syntax|javascript|973554|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

This answer might be arriving late but is an interesting find. Using compile can really save you time if you are planning on using the regex multiple times (this is also mentioned in the docs). Below you can see that using a compiled regex is the fastest when the match method is directly called on it. passing a compiled regex to re.match makes it even slower and passing re.match with the patter string is somewhere in the middle. 

<pre><code>&gt;&gt;&gt; ipr = r'\D+((([0-2][0-5]?[0-5]?)\.){3}([0-2][0-5]?[0-5]?))\D+'
&gt;&gt;&gt; average(*timeit.repeat("re.match(ipr, 'abcd100.10.255.255 ')", globals={'ipr': ipr, 're': re}))
1.5077415757028423
&gt;&gt;&gt; ipr = re.compile(ipr)
&gt;&gt;&gt; average(*timeit.repeat("re.match(ipr, 'abcd100.10.255.255 ')", globals={'ipr': ipr, 're': re}))
1.8324008992184038
&gt;&gt;&gt; average(*timeit.repeat("ipr.match('abcd100.10.255.255 ')", globals={'ipr': ipr, 're': re}))
0.9187896518778871
</code></pre>

blocks|key|3439867|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3439868|运行编译的正则表达式与动态编译相比，我有过上千次的经验，并且没有注意到任何明显的差异|blockquote|3439869|3439870|3439871|对被接受的答案的投票导致了这样的假设，即@Triptych所说的对所有情况都是正确的。这不一定是真的。一个很大的区别是您必须决定是接受regex字符串还是接受已编译的regex对象作为函数的参数：|3439872|>>>+timeit.timeit(setup="""
...+import+re
...+f=lambda+x,+y:+x.match(y)+++++++#+accepts+compiled+regex+as+parameter
...+h=re.compile('hello')
...+""",+stmt="f(h,+'hello+world')")
0.32881879806518555
>>>+timeit.timeit(setup="""
...+import+re
...+f=lambda+x,+y:+re.compile(x).match(y)+++#+compiles+when+called
...+""",+stmt="f('hello',+'hello+world')")
0.809190034866333|code-block|syntax|javascript|3439873|编译正则表达式总是更好，以防您需要重用它们。|3439874|注上面的timeit中的示例模拟了在导入时创建一次编译的regex对象，而不是在需要匹配时“即时创建”。|3439875|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|T|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|U|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|W|7|@]|8|@]|9|$]]|$1|H|3|I|4|J|6|X|7|@]|8|@]|9|$K|L]]|$1|M|3|N|4|5|6|Y|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|Z|7|@]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|10|7|@]|8|@]|9|$]]]|R|$]]

<blockquote>
 I've had a lot of experience running a compiled regex 1000s
 of times versus compiling on-the-fly, and have not noticed
 any perceivable difference
</blockquote>

The votes on the accepted answer leads to the assumption that what @Triptych says is true for all cases. This is not necessarily true. One big difference is when you have to decide whether to accept a regex string or a compiled regex object as a parameter to a function:

<pre><code>&gt;&gt;&gt; timeit.timeit(setup="""
... import re
... f=lambda x, y: x.match(y) # accepts compiled regex as parameter
... h=re.compile('hello')
... """, stmt="f(h, 'hello world')")
0.32881879806518555
&gt;&gt;&gt; timeit.timeit(setup="""
... import re
... f=lambda x, y: re.compile(x).match(y) # compiles when called
... """, stmt="f('hello', 'hello world')")
0.809190034866333
</code></pre>

It is always better to compile your regexs in case you need to reuse them. 

Note the example in the timeit above simulates creation of a compiled regex object once at import time versus "on-the-fly" when required for a match.

blocks|key|4286823|text|大多数情况下，无论您是否使用re.compile，都没有什么区别。在内部，所有函数都是通过编译步骤实现的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4286824|def+match(pattern,+string,+flags=0):
++++return+_compile(pattern,+flags).match(string)

def+fullmatch(pattern,+string,+flags=0):
++++return+_compile(pattern,+flags).fullmatch(string)

def+search(pattern,+string,+flags=0):
++++return+_compile(pattern,+flags).search(string)

def+sub(pattern,+repl,+string,+count=0,+flags=0):
++++return+_compile(pattern,+flags).sub(repl,+string,+count)

def+subn(pattern,+repl,+string,+count=0,+flags=0):
++++return+_compile(pattern,+flags).subn(repl,+string,+count)

def+split(pattern,+string,+maxsplit=0,+flags=0):
++++return+_compile(pattern,+flags).split(string,+maxsplit)

def+findall(pattern,+string,+flags=0):
++++return+_compile(pattern,+flags).findall(string)

def+finditer(pattern,+string,+flags=0):
++++return+_compile(pattern,+flags).finditer(string)|code-block|syntax|javascript|4286825|此外，re.compile()绕过了额外的间接和缓存逻辑：|4286826|_cache+=+{}

_pattern_type+=+type(sre_compile.compile("",+0))

_MAXCACHE+=+512
def+_compile(pattern,+flags):
++++#+internal:+compile+pattern
++++try:
++++++++p,+loc+=+_cache[type(pattern),+pattern,+flags]
++++++++if+loc+is+None+or+loc+==+_locale.setlocale(_locale.LC_CTYPE):
++++++++++++return+p
++++except+KeyError:
++++++++pass
++++if+isinstance(pattern,+_pattern_type):
++++++++if+flags:
++++++++++++raise+ValueError(
++++++++++++++++"cannot+process+flags+argument+with+a+compiled+pattern")
++++++++return+pattern
++++if+not+sre_compile.isstring(pattern):
++++++++raise+TypeError("first+argument+must+be+string+or+compiled+pattern")
++++p+=+sre_compile.compile(pattern,+flags)
++++if+not+(flags+&+DEBUG):
++++++++if+len(_cache)+>=+_MAXCACHE:
++++++++++++_cache.clear()
++++++++if+p.flags+&+LOCALE:
++++++++++++if+not+_locale:
++++++++++++++++return+p
++++++++++++loc+=+_locale.setlocale(_locale.LC_CTYPE)
++++++++else:
++++++++++++loc+=+None
++++++++_cache[type(pattern),+pattern,+flags]+=+p,+loc
++++return+p|4286827|除了使用re.compile带来的小速度优势外，人们还喜欢命名潜在的复杂模式规范并将其从应用的业务逻辑中分离出来的可读性：|4286828|####+Patterns+############################################################
number_pattern+=+re.compile(r'\d%2B(\.\d*)?')++++#+Integer+or+decimal+number
assign_pattern+=+re.compile(r':=')+++++++++++++#+Assignment+operator
identifier_pattern+=+re.compile(r'[A-Za-z]%2B')++#+Identifiers
whitespace_pattern+=+re.compile(r'[\t+]%2B')+++++#+Spaces+and+tabs

####+Applications+########################################################

if+whitespace_pattern.match(s):+business_logic_rule_1()
if+assign_pattern.match(s):+business_logic_rule_2()|4286829|注意，另一个受访者错误地认为pyc文件直接存储编译模式；然而，实际上，每次加载PYC时都会重新构建它们：|4286830|>>>+from+dis+import+dis
>>>+with+open('tmp.pyc',+'rb')+as+f:
++++++++f.read(8)
++++++++dis(marshal.load(f))

++1+++++++++++0+LOAD_CONST+++++++++++++++0+(-1)
++++++++++++++3+LOAD_CONST+++++++++++++++1+(None)
++++++++++++++6+IMPORT_NAME++++++++++++++0+(re)
++++++++++++++9+STORE_NAME+++++++++++++++0+(re)

++3++++++++++12+LOAD_NAME++++++++++++++++0+(re)
+++++++++++++15+LOAD_ATTR++++++++++++++++1+(compile)
+++++++++++++18+LOAD_CONST+++++++++++++++2+('[aeiou]{2,5}')
+++++++++++++21+CALL_FUNCTION++++++++++++1
+++++++++++++24+STORE_NAME+++++++++++++++2+(lc_vowels)
+++++++++++++27+LOAD_CONST+++++++++++++++1+(None)
+++++++++++++30+RETURN_VALUE|4286831|上面的反汇编来自包含以下内容的tmp.py的PYC文件：|offset|length|style|CODE|4286832|import+re
lc_vowels+=+re.compile(r'[aeiou]{2,5}')|4286833|entityMap^0|0|0|0|0|0|0|0|0|F|6|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|19|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1A|8|@$U|1B|V|1C|W|X]]|9|@]|A|$]]|$1|Y|3|Z|5|D|7|1D|8|@]|9|@]|A|$E|F]]|$1|10|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|11|$]]

Mostly, there is little difference whether you use re.compile or not. Internally, all of the functions are implemented in terms of a compile step:

<pre><code>def match(pattern, string, flags=0):
 return _compile(pattern, flags).match(string)

def fullmatch(pattern, string, flags=0):
 return _compile(pattern, flags).fullmatch(string)

def search(pattern, string, flags=0):
 return _compile(pattern, flags).search(string)

def sub(pattern, repl, string, count=0, flags=0):
 return _compile(pattern, flags).sub(repl, string, count)

def subn(pattern, repl, string, count=0, flags=0):
 return _compile(pattern, flags).subn(repl, string, count)

def split(pattern, string, maxsplit=0, flags=0):
 return _compile(pattern, flags).split(string, maxsplit)

def findall(pattern, string, flags=0):
 return _compile(pattern, flags).findall(string)

def finditer(pattern, string, flags=0):
 return _compile(pattern, flags).finditer(string)
</code></pre>

In addition, re.compile() bypasses the extra indirection and caching logic:

<pre><code>_cache = {}

_pattern_type = type(sre_compile.compile("", 0))

_MAXCACHE = 512
def _compile(pattern, flags):
 # internal: compile pattern
 try:
 p, loc = _cache[type(pattern), pattern, flags]
 if loc is None or loc == _locale.setlocale(_locale.LC_CTYPE):
 return p
 except KeyError:
 pass
 if isinstance(pattern, _pattern_type):
 if flags:
 raise ValueError(
 "cannot process flags argument with a compiled pattern")
 return pattern
 if not sre_compile.isstring(pattern):
 raise TypeError("first argument must be string or compiled pattern")
 p = sre_compile.compile(pattern, flags)
 if not (flags &amp; DEBUG):
 if len(_cache) &gt;= _MAXCACHE:
 _cache.clear()
 if p.flags &amp; LOCALE:
 if not _locale:
 return p
 loc = _locale.setlocale(_locale.LC_CTYPE)
 else:
 loc = None
 _cache[type(pattern), pattern, flags] = p, loc
 return p
</code></pre>

In addition to the small speed benefit from using re.compile, people also like the readability that comes from naming potentially complex pattern specifications and separating them from the business logic where there are applied:

<pre><code>#### Patterns ############################################################
number_pattern = re.compile(r'\d+(\.\d*)?') # Integer or decimal number
assign_pattern = re.compile(r':=') # Assignment operator
identifier_pattern = re.compile(r'[A-Za-z]+') # Identifiers
whitespace_pattern = re.compile(r'[\t ]+') # Spaces and tabs

#### Applications ########################################################

if whitespace_pattern.match(s): business_logic_rule_1()
if assign_pattern.match(s): business_logic_rule_2()
</code></pre>

Note, one other respondent incorrectly believed that pyc files stored compiled patterns directly; however, in reality they are rebuilt each time when the PYC is loaded:

<pre><code>&gt;&gt;&gt; from dis import dis
&gt;&gt;&gt; with open('tmp.pyc', 'rb') as f:
 f.read(8)
 dis(marshal.load(f))

 1 0 LOAD_CONST 0 (-1)
 3 LOAD_CONST 1 (None)
 6 IMPORT_NAME 0 (re)
 9 STORE_NAME 0 (re)

 3 12 LOAD_NAME 0 (re)
 15 LOAD_ATTR 1 (compile)
 18 LOAD_CONST 2 ('[aeiou]{2,5}')
 21 CALL_FUNCTION 1
 24 STORE_NAME 2 (lc_vowels)
 27 LOAD_CONST 1 (None)
 30 RETURN_VALUE
</code></pre>

The above disassembly comes from the PYC file for a <code>tmp.py</code> containing:

<pre><code>import re
lc_vowels = re.compile(r'[aeiou]{2,5}')
</code></pre>

blocks|key|222039|text|我真的很尊重上面所有的答案。在我看来是的！可以肯定的是，每次都使用re.compile而不是编译正则表达式是值得的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|222040|使用re.compile的|offset|length|style|BOLD|222041|使您的代码更加动态，因为您可以调用已经编译的正则表达式，而不是一次又一次地编译。在某些情况下，这会给你带来好处：|blockquote|222042|222043|222044|222045|Processor+Effort|ordered-list-item|222046|Time|222047|222048|(可以在findall，search，match中使用)|222049|并使您的程序看起来很酷。|222050|222051|示例:|222052|++example_string+=+"The+room+number+of+her+room+is+26A7B."
++find_alpha_numeric_string+=+re.compile(r"\b\w%2B\b")|code-block|syntax|javascript|222053|在Findall中使用|222054|+find_alpha_numeric_string.findall(example_string)|222055|在搜索中使用|222056|++find_alpha_numeric_string.search(example_string)|222057|与此类似，您可以将其用于：Match+|222058|+Substitute|222059|222060|entityMap^0|0|2|A|0|0|0|0|0|0|0|0|0|0|0|0|3|0|0|0|0|0|0|D|6|0|0|B|0|0^^$0|@$1|2|3|4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1L|8|@$D|1M|E|1N|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|1O|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|1S|8|@]|9|@]|A|$]]|$1|Q|3|R|5|P|7|1T|8|@]|9|@]|A|$]]|$1|S|3|-4|5|P|7|1U|8|@]|9|@]|A|$]]|$1|T|3|U|5|P|7|1V|8|@]|9|@]|A|$]]|$1|V|3|W|5|P|7|1W|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1Y|8|@$D|1Z|E|20|F|G]]|9|@]|A|$]]|$1|10|3|11|5|12|7|21|8|@]|9|@]|A|$13|14]]|$1|15|3|16|5|6|7|22|8|@]|9|@]|A|$]]|$1|17|3|18|5|12|7|23|8|@]|9|@]|A|$13|14]]|$1|19|3|1A|5|6|7|24|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|12|7|25|8|@]|9|@]|A|$13|14]]|$1|1D|3|1E|5|6|7|26|8|@$D|27|E|28|F|G]]|9|@]|A|$]]|$1|1F|3|1G|5|J|7|29|8|@$D|2A|E|2B|F|G]]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1I|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]]|1J|$]]

I really respect all the above answers. From my opinion
Yes! For sure it is worth to use re.compile instead of compiling the regex, again and again, every time. 

<blockquote>
 Using re.compile makes your code more dynamic, as you can call the already compiled regex, instead of compiling again and aagain. This thing benefits you in cases:
</blockquote>

<ol>
<li>Processor Efforts</li>
<li>Time Complexity.</li>
<li>Makes regex Universal.(can be used in findall, search, match)</li>
<li>And makes your program looks cool.</li>
</ol>

Example :

<pre><code> example_string = "The room number of her room is 26A7B."
 find_alpha_numeric_string = re.compile(r"\b\w+\b")
</code></pre>

<h1>Using in Findall</h1>

<pre><code> find_alpha_numeric_string.findall(example_string)
</code></pre>

<h1>Using in search</h1>

<pre><code> find_alpha_numeric_string.search(example_string)
</code></pre>

<blockquote>
 <blockquote>
 Similarly you can use it for: Match and Substitute
 </blockquote>
</blockquote>

blocks|key|4286957|text|除了表演之外。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4286958|使用compile可以帮助我区分|offset|length|style|CODE|4286959|1.模块(Re)，|4286960|2.+regex对象|4286961|3.匹配对象|4286962|当我开始学习正则表达式时|4286963|#regex+object
regex_object+=+re.compile(r'[a-zA-Z]%2B')
#match+object
match_object+=+regex_object.search('1.Hello')
#matching+content
match_object.group()
output:
Out[60]:+'Hello'
V.S.
re.search(r'[a-zA-Z]%2B','1.Hello').group()
Out[61]:+'Hello'|code-block|syntax|javascript|4286964|作为补充，我做了一个详尽的re模块小抄供您参考。|4286965|regex+=+{
'brackets':{'single_character':+['[]',+'.',+{'negate':'%5E'}],
++++++++++++'capturing_group'+:+['()','(?:)',+'(?!)'+'%7C',+'\\',+'backreferences+and+named+group'],
++++++++++++'repetition'++++++:+['{}',+'*?',+'%2B?',+'??',+'greedy+v.s.+lazy+?']},
'lookaround'+:{'lookahead'++:+['(?=...)',+'(?!...)'],
++++++++++++'lookbehind'+:+['(?<=...)','(?<!...)'],
++++++++++++'caputuring'+:+['(?P<name>...)',+'(?P=name)',+'(?:)'],},
'escapes':{'anchor'++++++++++:+['%5E',+'\b',+'$'],
++++++++++'non_printable'+++:+['\n',+'\t',+'\r',+'\f',+'\v'],
++++++++++'shorthand'+++++++:+['\d',+'\w',+'\s']},
'methods':+{['search',+'match',+'findall',+'finditer'],
++++++++++++++['split',+'sub']},
'match_object':+['group','groups',+'groupdict','start',+'end',+'span',]
}|4286966|entityMap^0|0|2|7|0|0|0|0|0|0|D|2|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@$D|12|E|13|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|14|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|17|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|18|8|@]|9|@]|A|$S|T]]|$1|U|3|V|5|6|7|19|8|@$D|1A|E|1B|F|G]]|9|@]|A|$]]|$1|W|3|X|5|R|7|1C|8|@]|9|@]|A|$S|T]]|$1|Y|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|Z|$]]

Besides the performance. 

Using <code>compile</code> helps me to distinguish the concepts of 
1. module(re), 
2. regex object 
3. match object 
When I started learning regex

<pre><code>#regex object
regex_object = re.compile(r'[a-zA-Z]+')
#match object
match_object = regex_object.search('1.Hello')
#matching content
match_object.group()
output:
Out[60]: 'Hello'
V.S.
re.search(r'[a-zA-Z]+','1.Hello').group()
Out[61]: 'Hello'
</code></pre>

As a complement, I made an exhaustive cheatsheet of module <code>re</code> for your reference.

<pre><code>regex = {
'brackets':{'single_character': ['[]', '.', {'negate':'^'}],
 'capturing_group' : ['()','(?:)', '(?!)' '|', '\\', 'backreferences and named group'],
 'repetition' : ['{}', '*?', '+?', '??', 'greedy v.s. lazy ?']},
'lookaround' :{'lookahead' : ['(?=...)', '(?!...)'],
 'lookbehind' : ['(?&lt;=...)','(?&lt;!...)'],
 'caputuring' : ['(?P&lt;name&gt;...)', '(?P=name)', '(?:)'],},
'escapes':{'anchor' : ['^', '\b', '$'],
 'non_printable' : ['\n', '\t', '\r', '\f', '\v'],
 'shorthand' : ['\d', '\w', '\s']},
'methods': {['search', 'match', 'findall', 'finditer'],
 ['split', 'sub']},
'match_object': ['group','groups', 'groupdict','start', 'end', 'span',]
}
</code></pre>

blocks|key|222148|text|根据Python+documentation|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|222149|该序列|222150|prog+=+re.compile(pattern)
result+=+prog.match(string)|code-block|syntax|javascript|222151|等同于|222152|result+=+re.match(pattern,+string)|222153|但是，当表达式在单个程序中多次使用时，使用re.compile()并保存生成的正则表达式对象以供重用会更有效。|style|CODE|222154|所以我的结论是，如果你要为许多不同的文本匹配相同的模式，你最好预编译它。|222155|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.python.org/2/library/re.html^0|9|D|0|0|0|0|0|0|L|C|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|C|$]]|$1|M|3|N|5|H|7|19|8|@]|9|@]|C|$I|J]]|$1|O|3|P|5|6|7|1A|8|@$A|1B|B|1C|Q|R]]|9|@]|C|$]]|$1|S|3|T|5|6|7|1D|8|@]|9|@]|C|$]]|$1|U|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]]|V|$W|$5|X|Y|Z|C|$10|11]]]]

According to the Python <a href="https://docs.python.org/2/library/re.html" rel="nofollow noreferrer">documentation</a>:
The sequence
<pre><code>prog = re.compile(pattern)
result = prog.match(string)
</code></pre>
is equivalent to
<pre><code>result = re.match(pattern, string)
</code></pre>
but using <code>re.compile()</code> and saving the resulting regular expression object for reuse is more efficient when the expression will be used several times in a single program.
So my conclusion is, if you are going to match the same pattern for many different texts, you better precompile it.

blocks|key|979022|text|作为另一种回答，因为我看到以前没有人提到过它，所以我将继续引用Python+3+docs|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|979023|979024|您是应该使用这些模块级函数，还是应该获取模式并自己调用其方法？如果你在一个循环中访问一个正则表达式，那么预编译它可以节省一些函数调用。在循环之外，由于内部缓存的存在，没有太大的区别。|blockquote|979025|979026|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.python.org/3/howto/regex.html#performing-matches^0|V|D|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

As an alternative answer, as I see that it hasn't been mentioned before, I'll go ahead and quote the <a href="https://docs.python.org/3/howto/regex.html#performing-matches" rel="nofollow noreferrer">Python 3 docs</a>:

<blockquote>
 Should you use these module-level functions, or should you get the pattern and call its methods yourself? If you’re accessing a regex within a loop, pre-compiling it will save a few function calls. Outside of loops, there’s not much difference thanks to the internal cache.
</blockquote>

blocks|key|3440152|text|易读性/认知负荷偏好|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3440153|对我来说，主要的收获是我只需要记住和阅读复杂的regex+API语法的一个形式-+<compiled_pattern>.method(xxx)形式，而不是和+re.func(<pattern>,+xxx)形式。|offset|length|style|CODE|BOLD|3440154|re.compile(<pattern>)是一个额外的样板，真的。|3440155|但在regex方面，额外的编译步骤不太可能是认知负载的主要原因。事实上，对于复杂的模式，您甚至可以通过将声明与随后在其上调用的任何regex方法分开来获得清晰度。|3440156|我倾向于首先在Regex101这样的网站中调优复杂的模式，甚至是在单独的最小测试脚本中，然后将它们引入我的代码中，因此将声明与使用分离也适合我的工作流程。|3440157|entityMap^0|0|15|U|27|N|25|1|0|0|L|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@$D|S|E|T|F|G]|$D|U|E|V|F|G]|$D|W|E|X|F|H]]|9|@]|A|$]]|$1|I|3|J|5|6|7|Y|8|@$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|K|3|L|5|6|7|11|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|12|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|P|$]]

<h3>Legibility/cognitive load preference</h3>

To me, the main gain is that I only need to remember, and read, one form of the complicated regex API syntax - the <code>&lt;compiled_pattern&gt;.method(xxx)</code> form rather than that and the <code>re.func(&lt;pattern&gt;, xxx)</code> form.

The <code>re.compile(&lt;pattern&gt;)</code> is a bit of extra boilerplate, true. 

But where regex are concerned, that extra compile step is unlikely to be a big cause of cognitive load. And in fact, on complicated patterns, you might even gain clarity from separating the declaration from whatever regex method you then invoke on it.

I tend to first tune complicated patterns in a website like Regex101, or even in a separate minimal test script, then bring them into my code, so separating the declaration from its use fits my workflow as well.

blocks|key|222307|text|下面是一个使用re.compile比使用requested快50倍的例子。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|222308|这一点与我在上面的评论中所说的是一样的，即当您的使用不能从编译缓存中获得太多好处时，使用re.compile可能是一个显著的优势。至少在一个特定的情况下会发生这种情况(我在实践中遇到)，即当以下所有情况都为真时：|222309|222310|您有很多正则表达式模式(多于re._MAXCACHE，其default当前为512)，并且|unordered-list-item|222311|您经常使用这些正则表达式，并且|222312|您连续使用相同模式的正则表达式之间被超过re._MAXCACHE个其他正则表达式分隔，以便在连续使用之间从缓存中刷新每个正则表达式。<代码>H212<代码>F213|222313|222314|import+re
import+time

def+setup(N=1000):
++++#+Patterns+'a.*a',+'a.*b',+...,+'z.*z'
++++patterns+=+[chr(i)+%2B+'.*'+%2B+chr(j)
++++++++++++++++++++for+i+in+range(ord('a'),+ord('z')+%2B+1)
++++++++++++++++++++for+j+in+range(ord('a'),+ord('z')+%2B+1)]
++++#+If+this+assertion+below+fails,+just+add+more+(distinct)+patterns.
++++#+assert(re._MAXCACHE+<+len(patterns))
++++#+N+strings.+Increase+N+for+larger+effect.
++++strings+=+['abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz']+*+N
++++return+(patterns,+strings)

def+without_compile():
++++print('Without+re.compile:')
++++patterns,+strings+=+setup()
++++print('searching')
++++count+=+0
++++for+s+in+strings:
++++++++for+pat+in+patterns:
++++++++++++count+%2B=+bool(re.search(pat,+s))
++++return+count

def+without_compile_cache_friendly():
++++print('Without+re.compile,+cache-friendly+order:')
++++patterns,+strings+=+setup()
++++print('searching')
++++count+=+0
++++for+pat+in+patterns:
++++++++for+s+in+strings:
++++++++++++count+%2B=+bool(re.search(pat,+s))
++++return+count

def+with_compile():
++++print('With+re.compile:')
++++patterns,+strings+=+setup()
++++print('compiling')
++++compiled+=+[re.compile(pattern)+for+pattern+in+patterns]
++++print('searching')
++++count+=+0
++++for+s+in+strings:
++++++++for+regex+in+compiled:
++++++++++++count+%2B=+bool(regex.search(s))
++++return+count

start+=+time.time()
print(with_compile())
d1+=+time.time()+-+start
print(f'--+That+took+{d1:.2f}+seconds.\n')

start+=+time.time()
print(without_compile_cache_friendly())
d2+=+time.time()+-+start
print(f'--+That+took+{d2:.2f}+seconds.\n')

start+=+time.time()
print(without_compile())
d3+=+time.time()+-+start
print(f'--+That+took+{d3:.2f}+seconds.\n')

print(f'Ratio:+{d3/d1:.2f}')|code-block|syntax|javascript|222315|我在笔记本电脑上得到的输出示例(Python+3.7.7)：|222316|With+re.compile:
compiling
searching
676000
--+That+took+0.33+seconds.

Without+re.compile,+cache-friendly+order:
searching
676000
--+That+took+0.67+seconds.

Without+re.compile:
searching
676000
--+That+took+23.54+seconds.

Ratio:+70.89|222317|我没有费心使用timeit，因为差异是如此明显，但我每次都会得到质量上相似的数字。请注意，即使没有re.compile，多次使用相同的正则表达式并转移到下一个并不是那么糟糕(仅比使用re.compile慢2倍)，但在另一种顺序下(循环许多正则表达式)，正如预期的那样，它要糟糕得多。此外，增加缓存大小也有效:只需在上面的setup()中设置re._MAXCACHE+=+len(patterns)+(当然，我不建议在生产中这样做，因为带有下划线的名称通常是“私有的”)将~23秒降回~0.7秒，这也符合我们的理解。|222318|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/452104/is-it-worth-using-pythons-re-compile#comment108948583_452104|1|https://github.com/python/cpython/blob/9d74658f0a6e8a9b8d6dcf199dda886f35c6ad68/Lib/re.py#L288^0|7|A|K|9|0|0|18|A|0|0|E|C|S|7|1|0|0|K|C|0|0|0|0|0|7|6|1D|A|2J|A|4G|7|4Q|S|0^^$0|@$1|2|3|4|5|6|7|1B|8|@$9|1C|A|1D|B|C]]|D|@$9|1E|A|1F|1|1G]]|E|$]]|$1|F|3|G|5|6|7|1H|8|@$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|1L|8|@$9|1M|A|1N|B|C]]|D|@$9|1O|A|1P|1|1Q]]|E|$]]|$1|L|3|M|5|K|7|1R|8|@]|D|@]|E|$]]|$1|N|3|O|5|K|7|1S|8|@$9|1T|A|1U|B|C]]|D|@]|E|$]]|$1|P|3|-4|5|6|7|1V|8|@]|D|@]|E|$]]|$1|Q|3|R|5|S|7|1W|8|@]|D|@]|E|$T|U]]|$1|V|3|W|5|6|7|1X|8|@]|D|@]|E|$]]|$1|X|3|Y|5|S|7|1Y|8|@]|D|@]|E|$T|U]]|$1|Z|3|10|5|6|7|1Z|8|@$9|20|A|21|B|C]|$9|22|A|23|B|C]|$9|24|A|25|B|C]|$9|26|A|27|B|C]|$9|28|A|29|B|C]]|D|@]|E|$]]|$1|11|3|-4|5|6|7|2A|8|@]|D|@]|E|$]]]|12|$13|$5|14|15|16|E|$17|18]]|19|$5|14|15|16|E|$17|1A]]]]

Here is an example where using <code>re.compile</code> is over 50 times faster, as <a href="https://stackoverflow.com/questions/452104/is-it-worth-using-pythons-re-compile#comment108948583_452104">requested</a>. 

The point is just the same as what I made in the comment above, namely, using <code>re.compile</code> can be a significant advantage when your usage is such as to not benefit much from the compilation cache. This happens at least in one particular case (that I ran into in practice), namely when all of the following are true:

<ul>
<li>You have a lot of regex patterns (more than <code>re._MAXCACHE</code>, whose <a href="https://github.com/python/cpython/blob/9d74658f0a6e8a9b8d6dcf199dda886f35c6ad68/Lib/re.py#L288" rel="noreferrer">default</a> is currently 512), and</li>
<li>you use these regexes a lot of times, and</li>
<li>you consecutive usages of the same pattern are separated by more than <code>re._MAXCACHE</code> other regexes in between, so that each one gets flushed from the cache between consecutive usages.</li>
</ul>

<pre class="lang-py prettyprint-override"><code>import re
import time

def setup(N=1000):
 # Patterns 'a.*a', 'a.*b', ..., 'z.*z'
 patterns = [chr(i) + '.*' + chr(j)
 for i in range(ord('a'), ord('z') + 1)
 for j in range(ord('a'), ord('z') + 1)]
 # If this assertion below fails, just add more (distinct) patterns.
 # assert(re._MAXCACHE &lt; len(patterns))
 # N strings. Increase N for larger effect.
 strings = ['abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz'] * N
 return (patterns, strings)

def without_compile():
 print('Without re.compile:')
 patterns, strings = setup()
 print('searching')
 count = 0
 for s in strings:
 for pat in patterns:
 count += bool(re.search(pat, s))
 return count

def without_compile_cache_friendly():
 print('Without re.compile, cache-friendly order:')
 patterns, strings = setup()
 print('searching')
 count = 0
 for pat in patterns:
 for s in strings:
 count += bool(re.search(pat, s))
 return count

def with_compile():
 print('With re.compile:')
 patterns, strings = setup()
 print('compiling')
 compiled = [re.compile(pattern) for pattern in patterns]
 print('searching')
 count = 0
 for s in strings:
 for regex in compiled:
 count += bool(regex.search(s))
 return count

start = time.time()
print(with_compile())
d1 = time.time() - start
print(f'-- That took {d1:.2f} seconds.\n')

start = time.time()
print(without_compile_cache_friendly())
d2 = time.time() - start
print(f'-- That took {d2:.2f} seconds.\n')

start = time.time()
print(without_compile())
d3 = time.time() - start
print(f'-- That took {d3:.2f} seconds.\n')

print(f'Ratio: {d3/d1:.2f}')
</code></pre>

Example output I get on my laptop (Python 3.7.7): 

<pre class="lang-none prettyprint-override"><code>With re.compile:
compiling
searching
676000
-- That took 0.33 seconds.

Without re.compile, cache-friendly order:
searching
676000
-- That took 0.67 seconds.

Without re.compile:
searching
676000
-- That took 23.54 seconds.

Ratio: 70.89
</code></pre>

I didn't bother with <code>timeit</code> as the difference is so stark, but I get qualitatively similar numbers each time. Note that even without <code>re.compile</code>, using the same regex multiple times and moving on to the next one wasn't so bad (only about 2 times as slow as with <code>re.compile</code>), but in the other order (looping through many regexes), it is significantly worse, as expected. Also, increasing the cache size works too: simply setting <code>re._MAXCACHE = len(patterns)</code> in <code>setup()</code> above (of course I don't recommend doing such things in production as names with underscores are conventionally “private”) drops the ~23 seconds back down to ~0.7 seconds, which also matches our understanding.

blocks|key|3440280|text|尽管这两种方法在速度上具有可比性，但您应该知道，如果您正在处理数百万次迭代，则仍然存在一些可以忽略不计的时间差。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3440281|下面是速度测试：|3440282|import+re
import+time

SIZE+=+100_000_000

start+=+time.time()
foo+=+re.compile('foo')
[foo.search('bar')+for+_+in+range(SIZE)]
print('compiled:++',+time.time()+-+start)

start+=+time.time()
[re.search('foo',+'bar')+for+_+in+range(SIZE)]
print('uncompiled:',+time.time()+-+start)|code-block|syntax|javascript|3440283|给出了以下结果：|3440284|compiled:+++14.647532224655151
uncompiled:+61.483458042144775|3440285|在我的PC上(使用Python+3.7.0)，编译方法的速度要快4倍左右。|3440286|正如documentation中所解释的|offset|length|3440287|3440288|如果你在一个循环中访问一个正则表达式，预编译它可以节省一些函数调用。在循环之外，由于内部缓存的存在，没有太大的区别。|blockquote|3440289|3440290|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.python.org/3/howto/regex.html#module-level-functions^0|0|0|0|0|0|0|2|D|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|17|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|18|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|19|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1A|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1B|8|@]|9|@$Q|1C|R|1D|1|1E]]|A|$]]|$1|S|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1G|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|Y|$Z|$5|10|11|12|A|$13|14]]]]

Although the two approaches are comparable in terms of speed, you should know that there still is some negligible time difference which might be of your concern if you're dealing with millions of iterations.
The following speed test:
<pre class="lang-py prettyprint-override"><code>import re
import time

SIZE = 100_000_000

start = time.time()
foo = re.compile('foo')
[foo.search('bar') for _ in range(SIZE)]
print('compiled: ', time.time() - start)

start = time.time()
[re.search('foo', 'bar') for _ in range(SIZE)]
print('uncompiled:', time.time() - start)
</code></pre>
gives these results:
<pre><code>compiled: 14.647532224655151
uncompiled: 61.483458042144775
</code></pre>
The compiled approach is on my PC (with Python 3.7.0) consistently about 4 times faster.
As explained in the <a href="https://docs.python.org/3/howto/regex.html#module-level-functions" rel="nofollow noreferrer">documentation</a>:
<blockquote>
If you’re accessing a regex within a loop, pre-compiling it will save a few function calls. Outside of loops, there’s not much difference thanks to the internal cache.
</blockquote>

Is there any benefit in using compile for regular expressions in Python?

<pre><code>h = re.compile('hello')
h.match('hello world')
</code></pre>

vs

<pre><code>re.match('hello', 'hello world')
</code></pre>

Is it worth using Python's re.compile?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在Python中使用编译正则表达式有什么好处吗？h = re.compile('hello')h.match('hello world')vsre.match('hello', 'hello world')

问使用Python的re.compile值得吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用Python的re.compile值得吗？EN