为什么在Scala中追加到列表的时间复杂度为O（n）？

我刚刚读到，List（：+）的追加操作的执行时间随的大小线性增长List。

追加到a List似乎很普通。为什么惯用的方法是在组件之前加上列表然后反转列表？这也不是设计失败，因为可以随时更改实现。

从我的角度来看，前置和附加都应为O（1）。

是否有任何正当理由？

我将扩大我的评论。对List[T]数据结构scala.collection.immutable进行了优化，使其以一种更纯粹的功能编程语言中的不可变列表的方式工作。它的挂起时间非常快，并且假定您将为几乎所有访问而工作。

由于不可变列表将链接列表建模为一系列“约束单元”，因此它们的前置时间非常快。单元格定义一个值，以及指向下一个单元格的指针（经典的单链列表样式）：

Cell [Value| -> Nil]

当您添加到列表之前时，实际上就是在创建一个新的单元格，而现有列表的其余部分则指向：

Cell [NewValue| -> [Cell[Value| -> Nil]]

由于列表是不可变的，因此您无需进行任何实际复制就可以放心地进行操作。不存在旧列表发生更改并导致新列表中的所有值变为无效的危险。但是，作为一种折衷办法，您将无法具有指向列表末尾的可变指针。

这很适合递归地处理列表。假设您定义了自己的版本filter：

def deleteIf[T](list : List[T])(f : T => Boolean): List[T] = list match {
  case Nil => Nil
  case (x::xs) => f(x) match {
    case true => deleteIf(xs)(f)
    case false => x :: deleteIf(xs)(f)
  }
}

这是一个递归函数，仅在列表的开头起作用，并通过::提取器利用模式匹配。在Haskell等语言中，您会看到很多这种东西。

如果您真的想要快速追加，Scala提供了很多可变和不变的数据结构供您选择。在可变的方面，您可能会考虑ListBuffer。或者，Vector从scala.collection.immutable具有较快的附加时间。