一些遗留代码一起工作，我遇到了因内存问题主要是（我相信）的广泛使用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