哈希和访问

发布于 2024-10-31 07:37:42 字数 678 浏览 6 评论 0原文

我想对我的对象使用哈希存储。这真的比 std::map 更快吗?我的意思是寻找。据我所知,boost过程进行了大量的优化。

而且我不确定我的代码是否正确。在搜索/插入等时它真的使用散列键吗?

using boost::multi_index_container;
using namespace boost::multi_index;

struct Object
{
  std::string name;

  Object(std::string name_): name(name_) {}
};

typedef multi_index_container<
  Object,
  indexed_by<
    hashed_unique<
      BOOST_MULTI_INDEX_MEMBER(Object, std::string, name)
    >
  >
> ObjectSet;

ObjectSet objects;
objects.insert(Object("test1"));
objects.insert(Object("test2"));
objects.insert(Object("test3"));

// And testing:
objects.find("test2");

I want to use hashed storage for my objects. Is this really faster, than std::map<std::string, Object>? I mean searching. As I know, boost process a lot of optimizing.

And I'm not sure my code is right. Does it really use hashed keys when searching/inserting, etc?

using boost::multi_index_container;
using namespace boost::multi_index;

struct Object
{
  std::string name;

  Object(std::string name_): name(name_) {}
};

typedef multi_index_container<
  Object,
  indexed_by<
    hashed_unique<
      BOOST_MULTI_INDEX_MEMBER(Object, std::string, name)
    >
  >
> ObjectSet;

ObjectSet objects;
objects.insert(Object("test1"));
objects.insert(Object("test2"));
objects.insert(Object("test3"));

// And testing:
objects.find("test2");

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

向地狱狂奔 2024-11-07 07:37:42

当您只有一个键时,为什么要使用 Boost 多索引容器?如果您不打算很快添加更多键,则应该使用 std::unordered_mapstd::map

至于哈希表与树:

例如,unordered_map 的 GCC 实现永远不会收缩其表,因此,如果您添加大量元素,然后删除其中大部分元素,那么您留下的数据局部性非常糟糕(因此数据局部性很差)缓存性能)。从算法上讲,哈希表可能很有吸引力,但在实际运行的系统中,它们的性能可能比树差,尤其是当元素数量为数百或更少时。

Why are you using Boost Multi-Index Container when you only have a single key? If you don't plan to add more keys soon, you should just use std::unordered_map, or std::map.

As for hash tables vs. trees:

The GCC implementation of unordered_map for example never shrinks its table, so if you add a lot of elements, then delete most of them, you are left with something that has pretty horrible data locality (and therefore poor performance w.r.t. caching). Algorithmically hash tables may be appealing, but in real, running systems they can exhibit worse performance than trees, especially when the number of elements is in the hundreds or less.

反话 2024-11-07 07:37:42

除了最极端的退化情况之外,在任何情况下,在 unordered_map (hash_map) 中使用散列键进行精确匹配查找都比使用 std::map 的底层红黑树更快。

是的,您的代码应该是正确的,假设有一个哈希函数接受 std::string 并返回其内容的哈希值。

Exact-match finding is, under any but the most extremely degenerate circumstances, faster using a hashed key in an unordered_map (hash_map) than the underlying red-black tree of std::map.

And yes, your code should be right, assuming that there is a hash function that takes std::string and returns a hash of its contents.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文