ChatGPT解决这个技术问题 Extra ChatGPT

When should I choose Vector in Scala?

It seems that Vector was late to the Scala collections party, and all the influential blog posts had already left.

In Java ArrayList is the default collection - I might use LinkedList but only when I've thought through an algorithm and care enough to optimise. In Scala should I be using Vector as my default Seq, or trying to work out when List is actually more appropriate?

I guess what I mean here is that in Java I would create write List<String> l = new ArrayList<String>() Scala blogs would have you believe that everybody uses List in order to get persistent collection goodness - but is Vector general-purpose enough that we should be using it in List's place?
@Debilski: I am wondering what you mean by that. I get a List when I type Seq() at REPL.
Hmm, well, it says so in the docs. Maybe this is only true for IndexedSeq.
The comment regarding the default concrete type of Seq is over three years old. As of Scala 2.11.4 (and earlier), the default concrete type of Seq is List.
For random access, vector is better. For head, tail access, list is better. For bulk operation, such as map, filter, vector is preferred since vector is organized with 32 elements as a chunk whereas list organized the elements with pointers to each other there is no guarantee these elements are close to each other.

s
simbo1905

As a general rule, default to using Vector. It’s faster than List for almost everything and more memory-efficient for larger-than-trivial sized sequences. See this documentation of the relative performance of Vector compared to the other collections. There are some downsides to going with Vector. Specifically:

Updates at the head are slower than List (though not by as much as you might think)

Another downside before Scala 2.10 was that pattern matching support was better for List, but this was rectified in 2.10 with generalized +: and :+ extractors.

There is also a more abstract, algebraic way of approaching this question: what sort of sequence do you conceptually have? Also, what are you conceptually doing with it? If I see a function that returns an Option[A], I know that function has some holes in its domain (and is thus partial). We can apply this same logic to collections.

If I have a sequence of type List[A], I am effectively asserting two things. First, my algorithm (and data) is entirely stack-structured. Second, I am asserting that the only things I’m going to do with this collection are full, O(n) traversals. These two really go hand-in-hand. Conversely, if I have something of type Vector[A], the only thing I am asserting is that my data has a well defined order and a finite length. Thus, the assertions are weaker with Vector, and this leads to its greater flexibility.


2.10 has been out for a while now, is the List pattern matching still better than Vector?
The list pattern matching is not better anymore. In fact, it's quite the contrary. For example, to get head and tail one can do case head +: tail or case tail :+ head. To match against empty, you can do case Seq() and so forth. Everything you need is there in the API, which is more versatile than List's
List is implemented with a singly-linked list. Vector is implemented something like Java's ArrayList.
@JosiahYoder It is implemented nothing like ArrayList. ArrayList wraps an array which it dynamically resizes. Vector is a trie, where the keys are the indexes of values.
I apologize. I was going on a web-source that was vague about the details. Should I correct my earlier statement? Or is that bad form?
D
Daniel C. Sobral

Well, a List can be incredibly fast if the algorithm can be implemented solely with ::, head and tail. I had an object lesson of that very recently, when I beat Java's split by generating a List instead of an Array, and couldn't beat that with anything else.

However, List has a fundamental problem: it doesn't work with parallel algorithms. I cannot split a List into multiple segments, or concatenate it back, in an efficient manner.

There are other kinds of collections that can handle parallelism much better -- and Vector is one of them. Vector also has great locality -- which List doesn't -- which can be a real plus for some algorithms.

So, all things considered, Vector is the best choice unless you have specific considerations that make one of the other collections preferable -- for example, you might choose Stream if you want lazy evaluation and caching (Iterator is faster but doesn't cache), or List if the algorithm is naturally implemented with the operations I mentioned.

By the way, it is preferable to use Seq or IndexedSeq unless you want a specific piece of API (such as List's ::), or even GenSeq or GenIndexedSeq if your algorithm can be run in parallel.


Thanks for the answer. What do you mean by "has great locality"?
@ngocdaothanh It means that data is grouped closely together in memory, improving the chance that data will be in the cache when you need it.
@user247077 Yes, Lists can beat Vectors in performance given the particulars I mentioned. And not all actions of vectors are amortized O(1). In fact, on immutable data structures (which is the case), alternate insert/deletions at either end will not amortize at all. In that case, the cache is useless because you are always copying the vector.
@user247077 Perhaps you are not aware that Vector is an immutable data structure in Scala?
@user247077 It's way more complicated than that, including some internally mutable stuff to make append cheaper, but when you use it as a stack, which is immutable list optimal scenario, you still end up having the same memory characteristics of a linked list, but with a much bigger memory allocation profile.
d
dth

Some of the statements here are confusing or even wrong, especially the idea that immutable.Vector in Scala is anything like an ArrayList. List and Vector are both immutable, persistent (i.e. "cheap to get a modified copy") data structures. There is no reasonable default choice as their might be for mutable data structures, but it rather depends on what your algorithm is doing. List is a singly linked list, while Vector is a base-32 integer trie, i.e. it is a kind of search tree with nodes of degree 32. Using this structure, Vector can provide most common operations reasonably fast, i.e. in O(log_32(n)). That works for prepend, append, update, random access, decomposition in head/tail. Iteration in sequential order is linear. List on the other hand just provides linear iteration and constant time prepend, decomposition in head/tail. Everything else takes in general linear time.

This might look like as if Vector was a good replacement for List in almost all cases, but prepend, decomposition and iteration are often the crucial operations on sequences in a functional program, and the constants of these operations are (much) higher for vector due to its more complicated structure. I made a few measurements, so iteration is about twice as fast for list, prepend is about 100 times faster on lists, decomposition in head/tail is about 10 times faster on lists and generation from a traversable is about 2 times faster for vectors. (This is probably, because Vector can allocate arrays of 32 elements at once when you build it up using a builder instead of prepending or appending elements one by one). Of course all operations that take linear time on lists but effectively constant time on vectors (as random access or append) will be prohibitively slow on large lists.

So which data structure should we use? Basically, there are four common cases:

We only need to transform sequences by operations like map, filter, fold etc: basically it does not matter, we should program our algorithm generically and might even benefit from accepting parallel sequences. For sequential operations List is probably a bit faster. But you should benchmark it if you have to optimize.

We need a lot of random access and different updates, so we should use vector, list will be prohibitively slow.

We operate on lists in a classical functional way, building them by prepending and iterating by recursive decomposition: use list, vector will be slower by a factor 10-100 or more.

We have an performance critical algorithm that is basically imperative and does a lot of random access on a list, something like in place quick-sort: use an imperative data structure, e.g. ArrayBuffer, locally and copy your data from and to it.


L
Luigi Plinge

For immutable collections, if you want a sequence, your main decision is whether to use an IndexedSeq or a LinearSeq, which give different guarantees for performance. An IndexedSeq provides fast random-access of elements and a fast length operation. A LinearSeq provides fast access only to the first element via head, but also has a fast tail operation. (Taken from the Seq documentation.)

For an IndexedSeq you would normally choose a Vector. Ranges and WrappedStrings are also IndexedSeqs.

For a LinearSeq you would normally choose a List or its lazy equivalent Stream. Other examples are Queues and Stacks.

So in Java terms, ArrayList used similarly to Scala's Vector, and LinkedList similarly to Scala's List. But in Scala I would tend to use List more often than Vector, because Scala has much better support for functions that include traversal of the sequence, like mapping, folding, iterating etc. You will tend to use these functions to manipulate the list as a whole, rather than randomly accessing individual elements.


But if Vector's iteration is faster than List's, and I can map fold etc as well, then apart from some specialised cases (essentially all those FP algorithms that are specialised to List) it seems that List is essentially legacy.
@Duncan where have you heard that Vector's iteration is faster? For a start, you need to keep track of and update the current index, which you don't need to with a linked list. I wouldn't call the list functions "specialised cases" - they are the bread and butter of functional programming. Not using them would be like trying to program Java without for- or while-loops.
I'm pretty sure Vector's iteration is faster, but someone needs to benchmark it to be sure.
I think (?) elements in Vector physically exist together on RAM in groups of 32, which more fully fit in the CPU cache... so there's less cache miss
D
Debilski

In situations which involve a lot random access and random mutation, a Vector (or – as the docs say – a Seq) seems to be a good compromise. This is also what the performance characteristics suggest.

Also, the Vector class seems to play nicely in distributed environments without much data duplication because there is no need to do a copy-on-write for the complete object. (See: http://akka.io/docs/akka/1.1.3/scala/stm.html#persistent-datastructures)


So much to learn... What does Vector being the default Seq mean? If I write Seq(1, 2, 3) I get List[Int] not Vector[Int].
If you have random access, use an IndexedSeq. Which is also Vector, but that's another matter.
@DuncanMcGregor: Vector is the default IndexedSeq which implements Seq. Seq(1, 2, 3) is a LinearSeq which is implemented using List.
J
Joshua Hartman

If you're programming immutably and need random access, Seq is the way to go (unless you want a Set, which you often actually do). Otherwise List works well, except it's operations can't be parallelized.

If you don't need immutable data structures, stick with ArrayBuffer since it's the Scala equivalent to ArrayList.


I'm sticking to the realm of immutable, persistent collections. My point is, that even if I don't need random access, has Vector effectively replaced List?
Depends a bit on the use case. Vectors are more balanced. The iteration is faster than list and random access is much faster. Updates are slower since it's not just a list prepend, unless it's a bulk update from a fold which can be done with a builder. That said, I think Vector is the best default choice since it is so versatile.
That I think gets to the heart of my question - Vectors are so good that we may as well use them where examples usually show List.