为什么处理排序数组要比未排序数组慢？

我有500000个随机生成的Tuple<long,long,string>对象的列表，在这些对象上执行简单的“之间”搜索：

var data = new List<Tuple<long,long,string>>(500000);
...
var cnt = data.Count(t => t.Item1 <= x && t.Item2 >= x);

当我生成随机数组并为100个随机生成的值运行搜索时x，搜索将在大约四秒钟内完成。知道排序确实会对搜索产生很大的影响，但是，我决定在运行100次搜索之前先对数据进行排序Item1，然后再按，再按Item2，最后按Item3- 进行排序。由于分支预测，我希望排序后的版本执行得更快：我的想法是，一旦到达Item1 == x，所有进一步的检查t.Item1 <= x都会正确地预测分支为“ no take”，从而加快分支的尾部。搜索。令我惊讶的是，在排序数组上进行搜索的时间是原来的两倍！

我尝试切换实验顺序，并为随机数生成器使用了不同的种子，但是效果是一样的：在未排序的数组中搜索的速度几乎是在同一数组中搜索速度的两倍，但是排序！

有谁能很好地解释这种奇怪的影响？我测试的源代码如下；我正在使用.NET 4.0。

private const int TotalCount = 500000;
private const int TotalQueries = 100;
private static long NextLong(Random r) {
    var data = new byte[8];
    r.NextBytes(data);
    return BitConverter.ToInt64(data, 0);
}
private class TupleComparer : IComparer<Tuple<long,long,string>> {
    public int Compare(Tuple<long,long,string> x, Tuple<long,long,string> y) {
        var res = x.Item1.CompareTo(y.Item1);
        if (res != 0) return res;
        res = x.Item2.CompareTo(y.Item2);
        return (res != 0) ? res : String.CompareOrdinal(x.Item3, y.Item3);
    }
}
static void Test(bool doSort) {
    var data = new List<Tuple<long,long,string>>(TotalCount);
    var random = new Random(1000000007);
    var sw = new Stopwatch();
    sw.Start();
    for (var i = 0 ; i != TotalCount ; i++) {
        var a = NextLong(random);
        var b = NextLong(random);
        if (a > b) {
            var tmp = a;
            a = b;
            b = tmp;
        }
        var s = string.Format("{0}-{1}", a, b);
        data.Add(Tuple.Create(a, b, s));
    }
    sw.Stop();
    if (doSort) {
        data.Sort(new TupleComparer());
    }
    Console.WriteLine("Populated in {0}", sw.Elapsed);
    sw.Reset();
    var total = 0L;
    sw.Start();
    for (var i = 0 ; i != TotalQueries ; i++) {
        var x = NextLong(random);
        var cnt = data.Count(t => t.Item1 <= x && t.Item2 >= x);
        total += cnt;
    }
    sw.Stop();
    Console.WriteLine("Found {0} matches in {1} ({2})", total, sw.Elapsed, doSort ? "Sorted" : "Unsorted");
}
static void Main() {
    Test(false);
    Test(true);
    Test(false);
    Test(true);
}

Populated in 00:00:01.3176257
Found 15614281 matches in 00:00:04.2463478 (Unsorted)
Populated in 00:00:01.3345087
Found 15614281 matches in 00:00:08.5393730 (Sorted)
Populated in 00:00:01.3665681
Found 15614281 matches in 00:00:04.1796578 (Unsorted)
Populated in 00:00:01.3326378
Found 15614281 matches in 00:00:08.6027886 (Sorted)

当您使用未排序的列表时，所有元组都以memory-order访问。它们已在RAM中连续分配。CPU喜欢顺序访问内存，因为它们可以推测性地请求下一个缓存行，因此该缓存行将在需要时始终存在。

在对列表进行排序时，您将其按随机顺序放置，因为排序键是随机生成的。这意味着对元组成员的内存访问是不可预测的。CPU无法预取内存，几乎对元组的每次访问都是高速缓存未命中。

这是一个很好的例子，说明了GC内存管理的特定优势：一起分配并一起使用的数据结构执行得非常好。他们有很大的借鉴意义。

在这种情况下，来自高速缓存未命中的代价大于所保存的分支预测代价。

尝试切换到struct-tuple。这将恢复性能，因为在运行时无需进行指针取消访问元组成员的操作。

克里斯·辛克莱尔（Chris Sinclair）在评论中指出：“对于TotalCount约10,000或更少，排序版本的执行速度更快 ”。这是因为一个小的列表完全适合CPU缓存。内存访问可能无法预测，但是目标始终在高速缓存中。我相信仍然会有很小的损失，因为即使从缓存中加载也需要一些周期。但这似乎不是问题，因为CPU可以处理多个未完成的负载，从而提高吞吐量。每当CPU遇到内存等待时，它仍将在指令流中加快速度，以尽可能多地排队存储操作。此技术用于隐藏延迟。

这种行为说明了预测现代CPU的性能有多么困难。从顺序内存访问到随机内存访问时我们的速度慢了2倍，这一事实告诉我隐藏内存延迟的过程到底有多少。内存访问会使CPU停顿50-200个周期。考虑到这一点，引入随机内存访问时，程序可能会变慢10倍以上。

LINQ不知道您的列表是否已排序。

由于Count with predicate参数是所有IEnumerable的扩展方法，因此我认为它甚至不知道它是否通过有效的随机访问运行在集合上。因此，它只检查每个元素，而Usr解释了为什么性能会降低。

要利用排序数组的性能优势（例如二进制搜索），您必须多做一些编码。