一些遺留代碼一起工作，我遇到了因內存問題主要是（我相信）的廣泛使用STL的地圖（特別是「地圖 - - 地圖」。）升壓flat_map容器
我在看提升flat_map作爲可能的解決方案。有沒有人有任何關於flat_maps的第一手經驗，尤其是關於速度和/或內存使用方面的改進？我當然意識到，這可能非常依賴於存儲的數據類型和存儲方式，但仍然對民間實際體驗感到好奇。
任何人都可以指出我一些可靠的例子嗎？
作爲一個例子：有幾種情況中的映射對的一地圖的這個代碼;即值爲另一個地圖的地圖。
通過用一對載體的更換「內」地圖，我減少內存佔用10：1（3G至300M）。當然，這可能會減慢搜索速度，但對於這種特殊情況，它似乎並不重要。它涉及重構和仔細測試的一天。
Boost的flat_map聽起來像它可能是正是我需要的，但我似乎無法找出太多關於它的其他比對升壓網站類的描述。尋找一些第一手的反饋。
Boost's flat_map是一種基於二叉樹的映射實現，除了二叉樹被存儲爲鍵值對的（排序）向量。
基本上可以找出答案就性能（相對於std::map自己基於這樣的事實：
在你的情況 - 地圖 - - 地圖 - 你會失去一些的「扁平化的東西出來」的好處，因爲你有一個外部地圖指向內部映射的指針（如果不是更多級別的間接尋址）;但平面地圖至少可以幫助你減少這種情況。另外，假設你有兩層地圖，你可以安排它，這樣你就可以存儲所有內部地圖連續地（或者通過適當地構造內部地圖或者通過用你自己的分配器來實例化它們，這是一件棘手的事情）;在這種情況下，您可以用地圖索引替換指向地圖的指針，從而減少佔用的空間並使編譯器的工作更輕鬆。
您可能還需要閱讀Boost的documentation of flat_map;你也可以使用武力，並閱讀the source（和source of the underlying flat_tree） - 像我一樣;我自己實際上沒有flat_map體驗。
我知道這是一個古老的問題，但這可能對找到此問題的人有用。
我發現flat_map在搜索，查找和迭代大地圖有了很大的改進。地圖在內存中使用連續數據的事實也使得插入速度比您預期的要快，這是由於數據的局部性很強。如果你在地圖上進行的插入比查找更多，那麼它可能不適合你。
話雖如此，反覆插入隨機值到排序向量是不是因爲數據位置的鏈表在同一更快 - 儘管什麼大O可能會告訴你。 （在VS2017和G ++ 4.8中測試）。
你說的「內存問題」呢？你可以再詳細一點嗎？ – beerboy 2013-03-07 02:31:09
內存過大。還有其他的嗎？說真的，我已經使用flat_map運行了一些測試，它似乎適用於我的目的。它不像使用一對載體那樣有效，但是alomost也很好，當然也更容易重構。 – user1074069 2013-03-08 15:17:23
你可以檢查一些東西：你是否收集垃圾（意思是，你是從地圖上刪除索引，而不是將其設置爲0）？並且可以通過將類型表示爲更小的類型來節省空間（例如，如果有很多重複的字符串，則使用枚舉而不是字符串）？ – EHuhtala 2013-03-18 19:00:03