2015-10-05 36 views
1

我有這樣一段代碼:爲什麼unordered_multiset作品不好等於多鍵

unordered_multiset<int> t; 
for (int i = 0; i < 1000000; i++) { 
    if (i % 10000 == 0) 
     cout << i << endl; 

    t.insert(10); 
} 

所以它只是把很多相等的元素在一個unordered_multiset。但是我發現我有更多的散列元素會更慢一些呢?我不明白原因。在我看來,在應用哈希函數並找到相等元素的桶(因爲所有相同的元素被組合在一起)之後,只需將它們放在桶的末尾。

那麼這裏有什麼問題?

UDP: 我發現unordered_multiset ::插入功能的描述

單元素插入: 平均情況:不變。 最差情況:容器大小呈線性。

所以,現在的問題可以表述爲:「爲什麼最糟糕的情況是線性的」

+0

我們在哈希中使用的更多元素更慢些,所以我們在這裏討論的是什麼操作?找到或插入? – basav

+1

它是不變的攤銷時間(即'O(1)')來查找存儲桶。但是桶afaik是一個鏈表。 – 101010

+0

我們正在討論插入。它如何在外部工作?爲什麼插入工作如此緩慢? – Nikita

回答

0

容器試圖通過重組存儲使平均桶大小是load_factor低於自身平衡。它通過添加更多桶來實現這一點,希望數據將更均勻地分佈。

當您在所有元素中存儲相同的值時,無論如何它們都會在同一個存儲桶中結束。哈希表最糟糕的可能條件!

1

一切都在同一個桶中。爲了把一些東西放在桶的最後,你必須找到桶的末端,桶中的東西越多,需要的時間就越長。

+0

爲什麼不存儲指向最後一個列表節點的指針以便更快地插入? – dyp

+0

爲什麼要這樣呢?性能約束不需要它,允許插入需要線性時間。而且這種操作在相當常見的操作上會有成本,比如插入帶有唯一鍵的值。每個實例都會支付這樣一個指針的代價,只有那些插入大量相等密鑰的指針纔會受益。這些情況可以自己優化操作,例如,通過使用映射到值列表。 –

+0

是的,我的問題是間接針對性能的限制。也就是說,我無法找到原因*爲什麼*允許插入線性時間。我同意,開銷可能是原因;但使用地圖使得列表(或間接)不再需要。 – dyp

相關問題