哪種數據結構更適合 - 堆或排序數組？

Question

我有一個程序：

1. 將一些數據從磁盤加載到 memory 中的std::map中。 std::map保持數據排序。

2. 將排序后的數據保存到磁盤

我想知道如果我這樣做堆是否會更快：

1. 將一些數據從磁盤加載到 memory 中的std::vector中。

2. 對向量進行排序

3. 將數據保存到磁盤

甚至使用堆：

1. 將一些數據從磁盤加載到 memory 中的std::vector中。

2. 在向量中堆

3. 從堆中彈出並將數據保存到磁盤

什么會最快？

Answer 1

漸近地，您的所有方法都是O(n log n) ：

• 在std::map中插入元素是容器大小的對數。 插入n 個元素將是O(n log n) 。
• 在std::vector上應用std::sort是O(n log n) 。
• 可以使用std::make_heap在線性時間內完成創建堆。 但是，從堆中彈出一個元素是堆大小的對數。 從堆中彈出n 個元素是O(n log n) 。

但是，我希望包括對std::vector和堆進行排序的方法比使用std::map的方法更快，因為由於更好的數據局部性，即這兩個中的元素，它們可以更多地利用緩存案例由 memory 中連續分配的塊組成，而不是像std::map那樣分布在 memory 中的節點。

另請注意，使用std::map的方法比其他兩個方法需要更多空間，因為指針將映射節點粘合在一起。

Answer 2

我想分享一些測試。

在這兩種情況下，我都使用我的自定義分配器，因此我可以檢查實際使用了多少 memory。

但是我的自定義分配器不適用於向量，因此不計算內部向量 memory （每條記錄 8 個字節），分配也傳遞給標准分配器（ operator new / malloc ）。

我不保留前面的向量，因為我不知道會有多少條記錄。

結論

Vector 更快，使用更少的內存！

---

使用類似 STL 的跳過列表的標准實現- 它比std::map慢 4-5%，但使用更少的 memory。

Processed    9940000 records. In memory    9940000 records,  310162322 bytes. Allocator  663018328 bytes.
Processed    9950000 records. In memory    9950000 records,  310477634 bytes. Allocator  663688048 bytes.
Processed    9960000 records. In memory    9960000 records,  310793005 bytes. Allocator  664357320 bytes.
Processed    9970000 records. In memory    9970000 records,  311108063 bytes. Allocator  665025016 bytes.
Processed    9980000 records. In memory    9980000 records,  311422710 bytes. Allocator  665694536 bytes.
Processed    9990000 records. In memory    9990000 records,  311738268 bytes. Allocator  666363680 bytes.
Processed   10000000 records. In memory    9999999 records,  312054428 bytes. Allocator  667035168 bytes.
Flushing data... List record(s):  9999999 List size:  312054428 

real    0m35.379s
user    0m34.218s
sys 0m1.072s

請注意，對於 312'054'428 字節的實際數據，它實際上使用了幾乎兩倍 - 667'035'168 字節。

---

矢量實現- std::vector ， std::sort ， std::unique ：

Processed    9890000 records. In memory    9890000 records,  308578515 bytes. Allocator  343196258 bytes.
Processed    9900000 records. In memory    9900000 records,  308895613 bytes. Allocator  343548385 bytes.
Processed    9910000 records. In memory    9910000 records,  309213506 bytes. Allocator  343901119 bytes.
Processed    9920000 records. In memory    9920000 records,  309531058 bytes. Allocator  344253602 bytes.
Processed    9930000 records. In memory    9930000 records,  309848406 bytes. Allocator  344605762 bytes.
Processed    9940000 records. In memory    9940000 records,  310162322 bytes. Allocator  344954565 bytes.
Processed    9950000 records. In memory    9950000 records,  310477634 bytes. Allocator  345304978 bytes.
Processed    9960000 records. In memory    9960000 records,  310793005 bytes. Allocator  345655307 bytes.
Processed    9970000 records. In memory    9970000 records,  311108063 bytes. Allocator  346005229 bytes.
Processed    9980000 records. In memory    9980000 records,  311422710 bytes. Allocator  346355138 bytes.
Processed    9990000 records. In memory    9990000 records,  311738268 bytes. Allocator  346705788 bytes.
Processed   10000000 records. In memory    9999999 records,  312054428 bytes. Allocator  347057202 bytes.
Flushing data... List record(s):  9999999 List size:  312054428 

real    0m12.759s
user    0m11.929s
sys 0m0.791s

---

使用 80 M 對進行測試：

2:08 對 6:17