Question

所以，今天我醒来时有了这个想法。

只是说，你有一个长的事物列表，一个数组，你必须检查每一个，找到一个匹配你正在寻找的东西。为此，您可以使用for循环。现在，想象一下，你正在寻找的那个几乎就在列表的末尾但是你不知道它。因此，在这种情况下，假设检查列表元素的顺序并不重要，那么从最后一个元素开始而不是第一个元素开始就更容易保存一些时间和记忆也许。但是，如果你的元素几乎处于开始状态怎么办？

当我想到的时候：如果我可以同时开始检查列表两端的元素怎么办？

所以，经过几次尝试，我想出了这个原始示例代码（用js编写），在我看来，这将解决我们上面定义的内容：

fx (var list) {
    var len = length(list);

    // To save some time as we were saying, we could check first if the array isn't as long as we were expecting
    if (len == 0) {
        // If it's not, then we just process the only element anyway
        /*
        ...
        list[0]
        ...
        */
        return;
    } else {
        // So, now here's the thing. The number of loops won't be the length of the list but just half of it.
        for (var i = 0; i == len/2; i++) {
            // And inside each loop we process both the first and last elements and so on until we reach the middle or find the one we're looking, whatever happens first
            /*
            ...
            list[i]
            list[len]
            ...
            */
            len--;
        }
    }

    return;
};

无论如何，我仍然不能完全确定这是否真的会加快这个过程，或者让它变得更慢或根本没有任何差别。这就是为什么我需要你的帮助，伙计们。

根据您自己的经验，您怎么看？这真的是一种让这种过程更快的好方法吗？如果是或不是，为什么？有没有办法改善它？

谢谢，伙计们。

Answer 1

如果您从两端工作，那么当您要寻找的项目接近中间时，您将获得最差的表现。无论你做什么，顺序搜索都是O（n）。

如果要加快搜索列表的速度，则需要使用更好的数据结构，例如排序列表，哈希表或B树。

Answer 2

你提出的算法很好如果你知道项目可能在开头或结尾但不在中间，如果它可能在中间，那就太糟糕了，如果它同样可能在列表中的任何位置。

一般情况下，如果你有一个未排序的 n 项目列表，那么你可能需要检查所有这些项目，这总是需要时间至少与n 成比例（这大致是符号“O（ n ）”的意思） - 除了从排序或部分排序的列表开始之外，没有办法解决这个问题

在你的方案中，循环仅运行 n / 2次迭代，但它在每次迭代中的工作量是普通线性搜索（从一端到另一端）的两倍，所以它的总成本大致相等。

如果你确实有一个部分排序的列表（也就是说，你有一些关于项目更可能的位置的信息），那么首先从最可能的位置开始是一个很好的策略。（假设你不经常寻找根本不在列表中的项目，在这种情况下没有任何帮助你。）

这是加速阵列处理的好方法吗？

2 个答案: