gpt4 book ai didi

c# - 内存索引

转载 作者:太空狗 更新时间:2023-10-29 19:44:32 25 4
gpt4 key购买 nike

我有一个 Session 的概念,它存储各种状态的对象。

有时我需要扫描 Session 以查找与特定查询匹配的对象,但我经常这样做,性能测试表明它正在成为某些领域的瓶颈。

因此我想介绍一下Session上索引的概念。

有点像...

public IDictionary<K, V> GetIndex<K, V>(Func<V, K> keySelector)

但是我不确定如何像这样测试 Func 的“相等性”。显然,我希望索引仅在第一次调用 GetIndex 时构建,随后的调用不会再次构建它。

我应该如何在内部映射这些以进行索引存在查找?

IDictionary<???, IDictionary<K, V>> indexes = ...

基本上我应该如何存储 ???.也许我不能使用 Func 来做到这一点,但也许还有其他方法。

最佳答案

最简单的方法可能是计算查询的散列,然后使用散列作为键将结果插入到字典中。

如果您的查询是字符串,您可以只使用 string.GetHashCode 函数来计算字符串数据的简单散列。如果您的查询是 Linq 查询,.GetHashCode 可能不会工作,除非 Linq 专门覆盖此方法来计算表达式树而不是默认对象实例指针的哈希。 .GetHashCode 的默认实现只是返回一个从内存中的对象实例标识派生的值,而不考虑对象的数据内容。

如果您的查询是字符串并且在构造上相当统一/一致,计算一个简单的字符串哈希应该足以减少使用缓存的查询流量。如果您的查询在结构上不太一致(例如,等效查询但参数顺序不同),您可能需要构建自己的哈希函数来计算输入查询的规范化形式的哈希,以提高查询的缓存命中率它们在逻辑上是等价的,但在文本上不同。

随着哈希计算的计算成本越来越高,使用缓存所带来的性能提升将会减少。确保查询操作足够昂贵以证明花时间计算哈希值和消耗缓存内存以产生执行时间的净节省。查询操作应该至少比散列计算和缓存管理开销大 2 个或更多个数量级。如果您的查询操作是进程外或跨网络调用,那么您的缓存开销几乎肯定会与查询成本相比相形见绌。

关于c# - 内存索引,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6061776/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com