用于键值查找的更简单的数据结构？
对于一小组键/值对（默认 2 个，最多 5 个），Dictionary 似乎有些过大了。有没有更简单的数据结构可以用于我的情况？我正在缓存某些对象的计算值（即
谢谢
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
对于一小组键/值对（默认 2 个，最多 5 个），Dictionary 似乎有些过大了。有没有更简单的数据结构可以用于我的情况？我正在缓存某些对象的计算值（即
谢谢
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（4）
在这种情况下，
List> （使用适当的容量创建）可能也同样有效......但它不会非常惯用。 （需要明确的是，您只需对每个关键元素调用Equals即可，完全忽略哈希码。）如果List对您来说有点沉重，如果您愿意，您甚至可以转到KeyValuePair[] 。恶心，但是嘿...这是你的代码。您是否真的尝试过
Dictionary并发现它太慢了？ “看起来有点矫枉过正”似乎不如“我已经尝试过，对其进行了分析，发现我的应用程序的时间花费在创建字典和查找其中的条目上，这是不可接受的。我需要我的应用程序具有 X 的性能特征，但目前我只有 Y。”如果您的键类型具有特定的顺序（并且如果您要对数据结构执行比创建实例更多的查找），您可以对列表进行排序，这意味着对于任何特定查找，您最多可以进行 3 次比较。如果您希望进行彻底优化，只需 5 个条目，您甚至可以对所有潜在路径进行硬编码。 （您甚至可能对 2、3、4 和 5 个元素有不同的实现。不过此时它变得有点愚蠢。）这基本上是一个
SortedList实现，但是您< em>也许能够针对您只有几个条目的场景对其进行一些优化。同样，值得首先尝试内置类型。重要的是，您知道这部分代码对您的整体性能到底有多重要 - 以及何时它“足够好”，以便您可以适当地停止。
A
List<KeyValuePair<TKey, TValue>>(created with an appropriate capacity) would probably work just as well in this case... but it wouldn't be terribly idiomatic. (Just to be clear, you'd simply callEqualson each key element, ignoring the hash code completely.) IfList<T>feels a bit heavy to you, you could even go down toKeyValuePair<TKey, TValue>[]if you wanted. Ick, but hey... it's your code.Have you actually tried
Dictionary<TKey, TValue>and found it to be too slow? "Seems like overkill" doesn't seem nearly as good an argument as "I've tried it, profiled it, and found an unacceptable amount of my application's time is spent creating dictionaries and looking up entries in them. I need my application to have performance characteristic X and at the moment I only have Y."If your key type has a particular ordering (and if you were going to perform more lookups on the data structure than you were going to create instances) you could sort the list, meaning you would have a maximum of 3 comparisons for any particular lookup. With only 5 entries you could even hard-code all the potential paths, if you were looking to optimize to the hilt. (You might even have different implementations for 2, 3, 4 and 5 elements. It's getting a little silly at that point though.) This is basically a
SortedList<TKey, TValue>implementation, but you may be able to optimize it a little for your scenario of only having a few entries. Again, it's worth trying the built-in types first.What's vital is that you know how important this part of your code really is to your overall performance - and when it will be "good enough" so you can stop appropriately.
如果键集在编译时已知，那么您可以简单地创建一个具有可空属性来保存值的类（或结构）。
If the set of keys is known at compile time, than you could simply create a class (or struct) with nullable properties that hold the values.
如果您使用像
KeyValuePair[] 这样的数组，您可以对其进行排序，然后使用二分搜索进行搜索。但只有当您必须排序一次然后多次检索时，这才算快。If you use an array like
KeyValuePair<TKey, TValue>[], you could sort it and then search using a binary search. But this is only fast if you have to sort once and then retrieve many times.我经常喜欢使用 Hashtable 类（http://msdn.microsoft.com/en-us/library/system.collections.hashtable.aspx）。
不过，您可以做的另一件事是不用担心自己管理任何缓存，只需使用 ASP.NET 的缓存即可。您所要做的就是包含 system.web 程序集，然后您甚至可以在非 Web 应用程序中使用它。这是一篇有关在 Windows 窗体应用程序中使用 .Net 缓存代码的文章。这真的很简单。
http://www.codeproject.com/KB/cs/cacheinwinformapps.aspx
D .
I often like to use the Hashtable class (http://msdn.microsoft.com/en-us/library/system.collections.hashtable.aspx).
Another thing you can do though, is not worry about managing any cache yourself and just use the caching from ASP.NET. All you have to do is include the system.web assembly and then you can use it even in non-web applications. Here's an article on using the .Net cache code in a Windows Forms app. It's really simple.
http://www.codeproject.com/KB/cs/cacheinwinformapps.aspx
D.