如果我错了，请纠正我，但 std::map 是一种有序的映射容器，因此每次插入一个值，map 都会使用一种算法来内部排序其项，这需要一些时间。
我的应用程序以恒定的间隔获取有关某些项目的信息。
这个应用程序保留一个定义如下的映射：
::std::map<DWORD, myItem*>
一开始所有的物品都被应用程序视为“新”的。一个“Item”对象被分配并添加到这个map中，将它的id和指向它的指针关联起来。
当它不是一个“新”的物品（只是对此对象的更新）时，我的应用程序应该在map中使用给定的id查找对象并进行更新。
大多数情况下我会得到更新。
我的问题是：
是否有任何更快的map实现，或者我应该继续使用这个？
我最好使用unordered_map吗？
我是更好使用unordered_map吗?
可能。
std:map提供O(log n)的一致性性能，因为它需要实现为平衡树。但std:unordered_map将被实现为哈希表，这可能会给您O(1)的性能（良好的哈希函数和跨哈希桶分配键），但它可能是O(n)（所有内容都在一个哈希桶中并退化为列表）。通常可以期望介于这些极端之间的某些东西。
因此，您可以始终拥有合理的性能（O(log n)）或者需要确保所有内容都适合哈希以获得良好的性能。
与任何此类问题一样：在承诺采用一种方法之前，您需要进行测量。除非您的数据集很大，否则您可能会发现没有显着的区别。
重要警告：除非您已经测量过（而您的问题表明您没有），映射性能对应用程序性能产生了实质性影响（大量时间用于搜索和更新映射），否则不要费力去使其更快。
坚持使用 std::map（或 std::unordered_map 或任何可用的 hash_map 实现）。
将应用程序加速1％可能并不值得努力。
相反，让它无错误。
回应Richard的答案：使用实际数据和真实类别测试使用不同的映射实现来衡量性能。
一些额外的注意事项:
了解预期成本的差异（哈希映射通常较低），最坏情况成本（平衡二叉树为O（logn），但如果插入触发哈希数组的重新分配，则哈希映射的成本要高得多），以及平摊成本（总成本除以操作或元素数;取决于新元素和现有元素的比率）。您需要找出在您的情况下哪个更具约束力。例如，如果您需要遵守非常低的延迟限制，则重新分配哈希映射可能太多。
找出真正的瓶颈所在。可能是在映射中搜索的成本与例如IO成本相比微不足道。
尝试更专业的映射实现。例如，如果您了解有关映射键的更多信息，则可以获得很多收益。通用映射实现作者没有此类知识。
在您的示例（32位无符号整数密钥强烈聚类，例如按顺序分配）中，可以使用基于基数的方法。 非常简单的示例（将其视为说明而不是可用食谱）：
Item *sentinel[65536]; // sentinel page, initialized to NULLs.
Item (*pages[65536])[65536]; // list of pages,
// initialized so every element points to sentinel
那么搜索就很简单：
Item *value = pages[index >> 16][index & 0xFFFF];
当您需要设置新值时：
if (pages[index >> 16] == sentinel) {
pages[index >> 16] = allocate_new_null_filled_page();
}
pages[index >> 16][index & 0xFFFF] = value;
优化你的地图实现。
例如，每个hash_map都喜欢预先知道大约有多少元素。这可以帮助避免哈希表不必要的重新分配和（可能）所有键的重新哈希。
对于上面我提到的专业例子，你肯定会尝试不同的页面大小，或者三级版本。
常见的优化是提供专门的内存分配器，以避免多次分配小对象。
new并用零进行memset即可。也许现在应该使用std::map（或std::unordered_map）... - Tomek Szpakowicz
unordered_map更加合适。只有在顺序很重要的情况下才应该使用map。不幸的是，unordered_map被引入得太晚了。但像@Neil所说，我也通过unordered_map获得了极大的性能提升，因为我只进行查找并且不关心顺序。但是，在进行大量插入和删除操作时，map往往会胜出。 - GManNickG