本文簡述了一種效能優化中常見的思維誤區

程式開發總是離不開效能優化,雖然規避不成熟優化的箴言早已有之,但我們又往往會被自己翻湧的思維火花所牽絆,義無反顧的開啟自己的效能劣化之旅…

考慮下面的一個簡單問題(以 C# 為例):

• 編寫一個字串修飾函式:給定一個字串,為其新增一個固定的字串字尾

這個函式在譬如檔案處理過程中很常用,程式碼也非常簡單:

const string SUFFIX = ".suffix";
public string Decorate(string str)
{
	return str + SUFFIX;
}

考慮到字串拼接操作比較耗費資源(一次記憶體分配操作和兩次字串拷貝操作),函式新增的字尾又是固定的(靜態),我們大可以將結果進行快取(假設記憶體是充足的),於是我們有了新的 Decorate 函式實現:

const string SUFFIX = ".suffix";
Dictionary<string, string> s_buffer = new Dictionary<string, string>();
public string DecorateCache(string str)
{
	if (!s_buffer.ContainsKey(str))
	{
		s_buffer.Add(str, str + SUFFIX);
	}
	
	return s_buffer[str];
}

至此,我們順利的完成了一次效能劣化…

WTF?

簡單編寫一個測試程式(給定的字串引數較短):

int perfCount = 1000000;
string path = "path";
			
{
	var stopWatch = Stopwatch.StartNew();
	
	for (int i = 0; i < perfCount; ++i)
	{
		StringUtil.Decorate(path);
	}
	
	Console.WriteLine("perf1 time " + stopWatch.ElapsedMilliseconds);
}

{
	var stopWatch = Stopwatch.StartNew();
	
	for (int i = 0; i < perfCount; ++i)
	{
		StringUtil.DecorateCache(path);
	}
	
	Console.WriteLine("perf2 time " + stopWatch.ElapsedMilliseconds);
}
 

發現 DecorateCache 函式的執行時間是 Decorate 函式的 1.5 倍!實際上,只有當新增的字尾字串(SUFFIX) 較長時(給定的字串引數較短), Decorate 函式的執行時間才會高於 DecorateCache 函式,但進一步的測試表明,新增的字尾字串長度需要 >= 80 才會出現這種情況,這在實際中基本是不會出現的,相反,給定的字串引數卻往往很長(譬如檔案路徑),所以更加符合實際的測試程式碼應該是這樣的(給定的字串引數較長):

int perfCount = 1000000;
string path = "longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglongpath";
			
{
	var stopWatch = Stopwatch.StartNew();
	
	for (int i = 0; i < perfCount; ++i)
	{
		StringUtil.Decorate(path);
	}
	
	Console.WriteLine("perf1 time " + stopWatch.ElapsedMilliseconds);
}

{
	var stopWatch = Stopwatch.StartNew();
	
	for (int i = 0; i < perfCount; ++i)
	{
		StringUtil.DecorateCache(path);
	}
	
	Console.WriteLine("perf2 time " + stopWatch.ElapsedMilliseconds);
}

這種情況下, DecorateCache 函式的執行時間是 Decorate 函式的 2 倍!

造成這種情況的原因其實是個偏工程的問題: Dictionary 的 indexer 和 ContainsKey 都涉及的內部函式 FindEntry 的實現.

這裡我們不去深入細節,只要知道 FindEntry 其實是個時間複雜度為 O(n) 的操作即可(n為給定字串引數的長度),而之前的 Decorate 函式雖然時間複雜度也是 O(n),但由於工程實現問題,實際上的執行速度是要更快的.

這裡還有一個變數: Decorate 函式涉及的一次記憶體分配.這導致我們不能簡單的對 Decorate 函式和 DecorateCache 函式做效能比較.

但我們仍然可以認為,一般情況下, Decorate 函式是優於 DecorateCache 函式的!

於是我們又迴歸了最初的函式實現:

const string SUFFIX = ".suffix";
public string Decorate(string str)
{
	return str + SUFFIX;
}

小結 : 對於效能優化,大膽假設,小心求證,信自己,更要信 Profiling

參考資料

• ILSpy

(CSDN的程式碼塊顯示格式縮排總有問題,不知是Bug還是自己使用不當,有知道的朋友麻煩告訴一聲~)