.net 什么时候使用元组比使用KeyValuePair更好？

每当我有一对相关的数据时，我通常使用

KeyValuePair

类型，从某种意义上说，一个是另一个的键。如果数据是不相关的，那么

元组

类型就更有意义了，我同意这种说法

现在我刚刚了解了为什么通常避免使用

KeyValuePair

而选择

Tuple

。主要参数是

元组的性能优势

在性能之外，是否有任何理由认为KVP比
元组更好？
KeyValuePair
是结构，而
元组
是类

这是影响对象复制方式（无论是通过引用还是通过值）的主要差异

因此，
Tuple
在32位操作系统中传递时只使用“4byte”，而
KeyValuePair
需要更多基于“K和V”的数据

无论如何，比较Tuple和KeyValuePair不是一个好主意（对我来说没有意义），因为两者都有不同的用途。
例如，可以认为该类型的名称不好。名为的KeyValuePair应该表示一个键和一个值。如果你的两个对象不是一个键和一个值，而是两个东西呢？如果我看到一个方法或属性的类型为
KeyValuePair
，我希望KVP的值是一个键和一个值。这实际上只是一个沟通意图的问题，并在将来向自己或其他团队成员表明这一点。元组并不表示这种关联

元组还可以更容易地添加另一个值，使其成为3元组（或三元组，不管您如何称呼它）。一些.NET语言，如F#，也使用元组

从实现的角度来看，
Tuple
做了很多事情
KeyValuePair
没有。元组是可比较的，它们实现了
IComparable
和
isstructuralequatable
接口，因此比较两个元组更容易。
你真的问错了问题，正确的问题是使用类（元组）比使用结构（KVP）更好在这种情况下，答案是你想用什么，这里给出的答案
尽管语义，性能可能是一个重要的考虑因素，因为你考虑这两个选项。如前所述，
KeyValuePair
是一种值类型（struct），而
Tuple
是一种引用类型（class）。因此，
KeyValuePair
在堆栈上分配，
Tuple
在堆上分配，最佳选择通常由的经典参数确定。简而言之，堆栈空间是有限的，但通常具有非常快速的访问。堆内存大得多，但速度稍慢

如果键和值类型都是原语（值类型如
int
、
bool
、
double
等）或小尺寸结构，则
KeyValuePair
可能是更好的选择。对于堆栈上的基元类型，分配和解除分配的速度非常快这确实会影响性能，尤其是递归方法调用的参数。

另一方面，如果
T1
或
T2
是引用类型（如类），则
Tuple
可能是更好的选择。包含指向引用类型（作为键或值类型）的指针的
KeyValuePair
有点不起作用，因为无论如何都需要在堆上查找对象

我在网上找到了一个基准测试：。这个基准测试的唯一问题是，他们测试了
KeyValuePair
与
Tuple
，而
字符串
类型在.NET中是一种不同寻常的特殊类型，因为它的行为既像值类型，又像引用类型，具体取决于执行上下文。我相信
KeyValuePair
将是对抗
Tuple
的明显赢家。然而，即使存在缺陷，结果也表明性能差异可能是显著的：

8.23 ns——分配元组

0.32 ns——分配KeyValuePair（快25倍！）

1.93 ns——将元组作为参数传递

2.57 ns--将KeyValuePair作为参数传递

1.91 ns——返回元组

6.09 ns—返回KeyValuePair

2.79 ns——从列表中加载元组

4.18 ns——从列表中加载KeyValuePair

KeyValuePair
是一个键和一个值，
Tuple
只是一对相等的值。您也可以问：“如果我可以使用
字典
，为什么我应该使用
列表
”。是的，但在这种情况下，您可以使用键查找数据。这意味着什么。在本例中，名称只是语义，它们（对处理器）没有任何意义。元组不是一对相等的值，而是一些相等的类型。这可能被视为吹毛求疵，但例如，C确实具有相同值的不同表示形式的并集结构。：）我发现了一个困难的方法，你可以将KeyValuePairs放入字典，但永远不会得到结果。此外，新的C#7.0支持新的、更简单的元组语法，使它们比KeyValuePairs更容易使用，性能也更高。此外，在元组中命名参数的功能使使用者更容易理解这些参数的用途。在像KVP这样的泛型中，任何人都可以猜测——除非有明确的文档记录——密钥应该是什么——也就是说，不是它的类型，而是它是什么真实世界的东西，比如一个设置名称、一个社会保险号等等。它们如何发挥不同的作用？请详细说明一下。@YakRangi keyvaluepair是用来作为字典中键和值的容器的，否则就没用了。另一方面，元组可以用来存储任意相关的成员。此外，使用Tuple，您可以存储多个成员，而不是组合存储