在linq中为什么后续调用IEnumerable.Intersect这么快
在看这个问题C＃两个数组的相似性时，注意到初始linq调用明显慢于后续调用。 正在缓存什么才能产生这样的差异？ 我感兴趣的是什么时候我们可以期望实现这种类型的行为（也许这只是因为相同的列表被反复使用）。
static void Main(string[] args) { var a = new List() { 7, 17, 21, 29, 30, 33, 40, 42, 51, 53, 60, 63, 66, 68, 70, 84, 85, 91, 101, 102, 104, 108, 109, 112, 115, 116, 118, 125, 132, 137, 139, 142, 155, 163, 164, 172, 174, 176, 179, 184, 185, 186, 187, 188, 189, 192, 197, 206, 209, 234, 240, 244, 249, 250, 252, 253, 254, 261, 263, 270, 275, 277, 290, 292, 293, 304, 308, 310, 314, 316, 319, 321, 322, 325, 326, 327, 331, 332, 333, 340, 367, 371, 374, 403, 411, 422, 427, 436, 440, 443, 444, 446, 448, 449, 450, 452, 455, 459, 467, 470, 487, 488, 489, 492, 494, 502, 503, 505, 513, 514, 522, 523, 528, 532, 534, 535, 545, 547, 548, 553, 555, 556, 565, 568, 570, 577, 581, 593, 595, 596, 598, 599, 606, 608, 613, 615, 630, 638, 648, 661, 663, 665, 669, 673, 679, 681, 685, 687, 690, 697, 702, 705, 708, 710, 716, 719, 724, 725, 727, 728, 732, 733, 739, 744, 760, 762, 775, 781, 787, 788, 790, 795, 797, 802, 806, 808, 811, 818, 821, 822, 829, 835, 845, 848, 851, 859, 864, 866, 868, 875, 881, 898, 899, 906, 909, 912, 913, 915, 916, 920, 926, 929, 930, 933, 937, 945, 946, 949, 954, 957, 960, 968, 975, 980, 985, 987, 989, 995 }; var b = new List() { 14, 20, 22, 23, 32, 36, 40, 48, 63, 65, 67, 71, 83, 87, 90, 100, 104, 109, 111, 127, 128, 137, 139, 141, 143, 148, 152, 153, 157, 158, 161, 163, 166, 187, 192, 198, 210, 211, 217, 220, 221, 232, 233, 236, 251, 252, 254, 256, 257, 272, 273, 277, 278, 283, 292, 304, 305, 307, 321, 333, 336, 341, 342, 344, 349, 355, 356, 359, 366, 373, 379, 386, 387, 392, 394, 396, 401, 409, 412, 433, 437, 441, 445, 447, 452, 465, 471, 476, 479, 483, 511, 514, 516, 521, 523, 531, 544, 548, 551, 554, 559, 562, 566, 567, 571, 572, 574, 576, 586, 592, 593, 597, 600, 602, 615, 627, 631, 636, 644, 650, 655, 657, 660, 667, 670, 680, 691, 697, 699, 703, 704, 706, 707, 716, 742, 748, 751, 754, 766, 770, 779, 785, 788, 790, 802, 803, 806, 811, 812, 815, 816, 821, 824, 828, 841, 848, 853, 863, 866, 870, 872, 875, 879, 880, 882, 883, 885, 886, 887, 888, 892, 894, 902, 905, 909, 912, 913, 914, 916, 920, 922, 925, 926, 928, 930, 935, 936, 938, 942, 945, 952, 954, 955, 957, 959, 960, 961, 963, 970, 974, 976, 979, 987 }; var s = new System.Diagnostics.Stopwatch(); const int cycles = 10; for (int i = 0; i < cycles; i++) { s.Start(); var z= a.Intersect(b); s.Stop(); Console.WriteLine("Test 1-{0}: {1} {2}", i, s.ElapsedTicks, z.Count()); s.Reset(); a[0]=i;//simple attempt to make sure entire result isn't cached } for (int i = 0; i < cycles; i++) { var z1 = new List(a.Count); s.Start(); int j = 0; int b1 = b[j]; foreach (var a1 in a) { while (b1 = b.Count) break; b1 = b[j]; } } s.Stop(); Console.WriteLine("Test 2-{0}: {1} {2}", i, s.ElapsedTicks, z1.Count); s.Reset(); a[0]=i;//simple attempt to make sure entire result isn't cached } Console.Write("Press Enter to quit"); Console.ReadLine(); } } 根据某些要求 – 示例输出：
Test 1-0: 2900 45 Test 1-1: 2 45 Test 1-2: 0 45 Test 1-3: 1 45
（正常循环显示连续运行之间只有轻微差异）
改变之后注意调用a.Intersect(b).ToArray(); 而不just a.Intersect(b); 正如@kerem所建议的那样，结果变为：
Test 1-0: 13656 45 Test 1-1: 113 45 Test 1-2: 76 45 Test 1-3: 64 45 Test 1-4: 90 45 ...
我希望任何循环的第一次运行都会变慢，原因有三：
- 代码必须在第一次进行，但不能随后进行。
- 如果运行的可执行代码足够小以适应缓存，则它不会被驱逐，并且加载CPU的速度更快。
- 如果数据足够小以适应缓存，则它不会被驱逐，并且加载CPU的速度更快。
LINQ大量使用延迟执行。 除非您枚举查询，否则它不会被执行。
更改
s.Start(); z= a.Intersect(b); s.Stop();
至
s.Start(); z= a.Intersect(b).**ToArray**(); s.Stop();
并请发布新的绩效结果。
a.Intersect（b）表示一个表达式，与a和b的值无关。 仅当通过枚举计算表达式时才使用a和b的值。
Enumerable.Intersect不执行任何缓存。 它是使用HashSet实现的。 第一个序列被添加到HashSet 。 然后从HashSet删除第二个序列。 HashSet的其余元素作为可枚举的元素序列产生。 您必须实际枚举HashSet以支付创建HashSet的成本。 即使对于小型集合，这种实现也令人惊讶地高效。
如果您在后续调用中看到性能上的差异，那不是因为Enumerable.Intersect执行任何缓存，但可能是因为您需要“预热”您的基准测试。
JITting System.Enumerable。
把新的List（）。相交（new List（））; new System.Diagnostics.Stopwatch（）。Stop（）; 作为您的第一行代码和所有交互将花费相同的时间。
只有在调用Count()时才会枚举Intersect()的结果; 当交叉点的计算实际发生时。 您计时的部分是创建可枚举对象， 该对象表示交集的未来计算 。
除了其他人注意到的jitting惩罚之外，第一次调用Intersect()可能是第一次使用System.Core.dll中的类型，因此您可能正在查看将IL代码加载到内存中所需的时间，如好。