STL之map容器速率測試

摘要

不止一次在使用 map 時被卡時限，map 是 c++ 的 STL 中一個常用且方便的容器，其是基於樹來實現的，它的插入與查找效率實際上更接近O(log N )（N爲插入的元素個數）。當然在 c++ 的 STL 中還有用哈希實現的無序關聯容器，這裏不做討論。
在實際應用中，常常會有人把 map 時間複雜度看作O(1)，確實在大多數時候 map 表現是令人滿意的，但在大量使用的時候，map卻不盡人意。

我們將測試如下幾種情形下使用 map 容器的效率（時間）：

• 僅插入元素（元素類型爲int）
• 插入以及查找（元素類型爲int）

測試環境準備

爲了給定一個對照的標準，先給出如下數據：

• 測試機空循環 1e6 次平均花費 0.0641 s
• 測試機讀取 1e6 個int型數據（快讀+從文件輸入）平均花費 0.2142 s

測試結果

僅插入元素

本機平均花費時間： 1.1015 s
測試代碼

const int P = 1e9+7;
map<int,int> mp;
int main(){
	int n = 1e6;
	long long gap = 1;
	for(int i = 1;i <= n;i++){
		mp[i*gap%P] = 1; gap += 1;
	}
	return 0;
}

插入以及查找元素

本機平均花費時間： 1.238 s
測試代碼

const int P = 1e9+7;
map<int,int> mp;
int main(){
	int n = 1e6;
	long long gap = 1;
	for(int i = 1;i <= n;i++){
		mp[i*gap%P] = 1; gap += 1;
	}
	for(int i = 1;i <= n;i++)
		if(mp.count(i));
	return 0;
}

小結

總體上測試結果是符合預期的，雖然 STL 容器已經很優化的，但是畢竟還是用樹來實現的，達不到 O(1) 的時間複雜度，所以如果是對時限要求很高的話，最好還是採用手動寫哈希表。
上述設計的實驗有很多缺陷，如未對 long long轉化、取模 以及其它多餘的操作進行排除影響，另外本來還測試了char、string、set等類型的元素，但是要設計一個好的測試代碼太麻煩了，就刪了，總的結論來說就是 int 是所有測試的數據類型中最慢的一種（甚至慢於 set 和 string ，如果只考慮插入和查找）。
最終結論就是如果需要一個 O(1) 時間複雜度的插入和查找（int 類型的元素），那麼就用哈希表。