99%的情況下沒必要多加一個RegexOptions.Compiled選項
而編譯後帶來的匹配速度提升多數情況下可以忽律不計。
//==============================
如下產生執行個體
Regex regExp = new Regex(@"\$List:\{(.*)\}\$", RegexOptions.IgnoreCase | RegexOptions.Singleline | RegexOptions.Compiled);
使用RegexOptions.Compiled時啟動速度明顯很慢,
如要使用建議將regExp聲明成static(全域對象),或者緩衝起來,也可以直接使用Regex類方法如:
Match match=Regex.Match(input, @"\$List:\{(.*)\}\$", RegexOptions.IgnoreCase | RegexOptions.Singleline | RegexOptions.Compiled ); 使用Regex的靜太方法時Regex將被緩衝起來
避免如下寫法
public string MyReplace(string input){
Regex regExp = new Regex(@"\$List:\{(.*)\}\$", RegexOptions.IgnoreCase | RegexOptions.Singleline | RegexOptions.Compiled);
return regExp.Replace(....)
}
參考文章內容:
來自:http://it.dianping.com/regexoptions-compiled.htm
//==============================================
曾經一位同事在寫程式時發現在利用Regex匹配文本時的效率很低。首先可以排除是Regex本身的問題,因為所使用的Regex是十分簡單的,匹配的文本量也不算大。檢查的時候去掉了RegexOptions.Compiled的選項之後,程式整體速度得到了很大的提升。
這是因為誤解了RegexOptions.Compiled這個選項提供的功能。在正則引擎啟動Regex之前,需要做一些準備工作,這些準備工作包括檢查Regex是否符合格式規範,並將其轉化能夠實際應用的內部形式。在許多關於Regex的文檔中,將這一過程用compile來描述。然而在.NET中,這個過程實際上是以parsing來描述的。
在.NET中,parsing是指在程式執行過程中,第一次遇到Regex時必須檢查它是否格式規範,並將其轉換為適於.NET正則引擎實際應用的內部形式。
當指定RegexOptions.Compiled的時候,所提供的機制是告訴正則引擎,除了將Regex轉換為認定的內部形式外,還將其編譯(很多人會混淆這裡的編譯和parsing的過程)為底層的MSIL(Microsoft Intermediate Language)代碼,在Regex實際應用時,可以由JIT(Just-In-Time)最佳化為更快的本地機器代碼。
啟動這個選項究竟對效能產生了怎樣的影響,可以從三個方面來看。
首先在啟動速度上,在不使用RegexOptions.Compiled會比較快,使用了RegexOptions.Compiled情況下,通常會使啟動速度慢許多,據說最多是60倍。
在記憶體佔用方面,使用RegexOptions.Compiled時,通常每個運算式會佔用5KB~15KB的記憶體,更重要的是,在程式執行過程中,這塊記憶體是無法被釋放的。這裡有時會帶來一些問題,因為Regex在.NET中作為對象被封裝,如果是多個進程或請求同時調用到這個程式碼片段,可能會造成相同的Regex在重複佔用了記憶體,這取決於程式具體的實現方式。
在匹配速度方面,RegexOptions.Compiled是可以提升匹配速度的,但是因為有在啟動速度和記憶體佔用方面帶來的額外開銷,所以除非是在需要匹配大量的文本和反覆使用某Regex時,這種提升非常不明顯,而且在許多人誤用此選項的情況下,得到的結果反而是程式整體運行速度的下降。所以在非大量文本處理的情況下,如果對程式整體效率有嚴格要求,建議不要使用該選項。
如果需要使用該選項,那麼一個應該考慮的也是更好的方案應該是將要使用的正則對象封裝到一個DLL中,這將使最終的程式佔用的記憶體更少,因為不必裝載使用RegexOptions.Compiled編譯Regex的包。另外,由於在封裝DLL時Regex已經編譯好了,裝載的速度也就得到了提升。附帶的一個好處就是這個包還可以提供給其他需要的程式員調用,而不是copyRegex的代碼。