.NET 队列 ElementAt 性能

Question

我的部分代码很难处理：

    private void UpdateOutputBuffer()
    {
        T[] OutputField = new T[DisplayedLength];

        int temp = 0;
        int Count = HistoryQueue.Count;
        int Sample = 0;

        //Then fill the useful part with samples from the queue
        for (temp = DisplayStart; temp != DisplayStart + DisplayedLength && temp < Count; temp++)
        {
            OutputField[Sample++] = HistoryQueue.ElementAt(Count - temp - 1);
        }

        DisplayedHistory = OutputField;
    }

大部分时间都在程序中。 HistoryQueue 中的元素数量为 200k+。 这可能是因为.NET 中的队列在内部是作为链表实现的吗？

有什么更好的方法来解决这个问题？ 基本上，该类应该像一个 FIFO 一样开始丢弃大约 500k 个样本的元素，我可以选择 DisplayedLength 元素并将它们放入 OutputField。我正在考虑编写自己的使用循环缓冲区的队列。

代码在计算较低的值时运行良好。 DisplayedLength 为 500。

谢谢你，

大卫

Answer 1

队列没有ElementAt 方法。我猜你是通过 Linq 得到的，它只是对 n 个元素进行强制迭代，直到它达到所需的索引。随着收藏变得越来越大，这显然会放慢速度。如果ElementAt 代表一个常见的访问模式，那么选择一个可以通过索引访问的数据结构，例如一个Array。

Answer 2

是的，链接列表几乎肯定是问题所在。 Queue<T> 没有实现 IList<T> 是有原因的 :)（话虽如此，我相信 Stack<T> 是使用数组实现的，但仍然没有实现 IList<T>。它可以 em> 提供有效的随机访问，但它没有。）

我无法轻易判断您要显示队列的哪一部分，但我强烈怀疑您可以简化方法并使用以下方法使其更高效：

T[] outputField = HistoryQueue.Skip(...) /* adjust to suit requirements... */
                              .Take(DisplayedLength)
                              .Reverse()
                              .ToArray();

这仍然需要单独跳过大量项目，但至少只需执行一次。

你有没有想过直接使用LinkedList<T>？这样可以更轻松地从列表末尾读取项目。

当然，使用循环缓冲区构建您自己的有界队列并不难，而且从长远来看可能是更好的解决方案。

Answer 3

这里使用的数据结构绝对是错误的。 ElementAt 是 O(n)，这使得你的循环 O(n²)。您应该使用其他东西而不是队列。

Answer 4

就我个人而言，我不认为队列是您要寻找的，但您的访问模式更糟。如果您想要顺序访问，请使用迭代器：

foreach(var h in HistoryQueue.Skip(DisplayStart).Take(DisplayedLength).Reverse())
    // work with h

Answer 5

如果您需要能够在任一端弹出/推送并且具有索引访问权限，您确实需要实现Deque（多数组形式）。虽然 BCL 中没有实现，但有很多第三方实现（开始，如果需要，您可以稍后实现自己的）。