Quand dois-je choisir Vector dans Scala?

Il semble que Vectorc'était tard pour la soirée des collections Scala, et tous les articles de blog influents étaient déjà partis.

En Java, ArrayListc'est la collection par défaut - je pourrais l'utiliser, LinkedListmais seulement lorsque j'aurai réfléchi à un algorithme et que je me soucierai suffisamment pour l'optimiser. Dans Scala, dois-je utiliser Vectorpar défaut Seqou essayer de déterminer quand Listest-ce réellement plus approprié?

En règle générale, utilisez par défaut Vector. C'est plus rapide que Listpour presque tout et plus efficace en mémoire pour les séquences de taille plus grande que triviale. Consultez cette documentation sur les performances relatives de Vector par rapport aux autres collections. Il y a des inconvénients à y aller Vector. Plus précisément:

• Les mises à jour en tête sont plus lentes que List(mais pas autant que vous le pensez)

Un autre inconvénient avant Scala 2.10 était que le support de correspondance de modèles était meilleur List, mais cela a été corrigé en 2.10 avec des généralisateurs +:et des :+extracteurs.

Il existe également une manière plus abstraite et algébrique d'aborder cette question: quelle sorte de séquence avez-vous conceptuellement ? De plus, qu'en faites-vous conceptuellement ? Si je vois une fonction qui renvoie unOption[A] , je sais que cette fonction a quelques trous dans son domaine (et est donc partielle). Nous pouvons appliquer cette même logique aux collections.

Si j'ai une séquence de type List[A], j'affirme effectivement deux choses. Premièrement, mon algorithme (et mes données) est entièrement structuré en pile. Deuxièmement, j'affirme que les seules choses que je vais faire avec cette collection sont des traversées complètes O (n). Ces deux vont vraiment de pair. Inversement, si j'ai quelque chose de type Vector[A], la seule chose que j'affirme, c'est que mes données ont un ordre bien défini et une longueur finie. Ainsi, les affirmations sont plus faibles avec Vector, et cela conduit à une plus grande flexibilité.

Eh bien, a Listpeut être incroyablement rapide si l'algorithme peut être implémenté uniquement avec ::, headet tail. J'ai eu une leçon d'objet très récemment, quand j'ai battu Java spliten générant un Listau lieu d'un Array, et je ne pouvais pas battre ça avec autre chose.

Cependant, Lista un problème fondamental: il ne fonctionne pas avec des algorithmes parallèles. Je ne peux pas diviser un Listen plusieurs segments, ni le concaténer de manière efficace.

Il existe d'autres types de collections qui peuvent mieux gérer le parallélisme - et Vectorc'est l'un d'entre eux. Vectora également une grande localité - ce qui Listn'est pas le cas - ce qui peut être un vrai plus pour certains algorithmes.

Donc, tout bien considéré, Vectorest le meilleur choix, sauf si vous avez des considérations spécifiques qui rendent l'une des autres collections préférable - par exemple, vous pouvez choisir Streamsi vous voulez une évaluation et une mise en cache paresseuses ( Iteratorest plus rapide mais ne met pas en cache), ou Listsi l'algorithme est naturellement implémenté avec les opérations que j'ai mentionnées.

Soit dit en passant, il est préférable d'utiliser Seqou à IndexedSeqmoins que vous ne vouliez un morceau spécifique d'API (comme celui Listde ::), ou même GenSeqou GenIndexedSeqsi votre algorithme peut être exécuté en parallèle.

Certaines des déclarations ici sont déroutantes ou même fausses, en particulier l'idée qu'immuable.Vector dans Scala est quelque chose comme une ArrayList. La liste et le vecteur sont tous deux des structures de données immuables et persistantes (c'est-à-dire «bon marché pour obtenir une copie modifiée»). Il n'y a pas de choix par défaut raisonnable car il pourrait s'agir de structures de données mutables, mais cela dépend plutôt de ce que fait votre algorithme. List est une liste liée individuellement, tandis que Vector est un trie de base 32, c'est-à-dire qu'il s'agit d'une sorte d'arbre de recherche avec des nœuds de degré 32. En utilisant cette structure, Vector peut fournir les opérations les plus courantes raisonnablement rapidement, c'est-à-dire en O (log_32 ( n)). Cela fonctionne pour le préfixe, l'ajout, la mise à jour, l'accès aléatoire, la décomposition en tête / queue. L'itération dans un ordre séquentiel est linéaire. La liste, en revanche, fournit juste une itération linéaire et un pré-ajout à temps constant, une décomposition en tête / queue.

Cela pourrait ressembler à si Vector était un bon remplacement pour List dans presque tous les cas, mais le préfixe, la décomposition et l'itération sont souvent les opérations cruciales sur les séquences d'un programme fonctionnel, et les constantes de ces opérations sont (beaucoup) plus élevées pour le vecteur dû à sa structure plus compliquée. J'ai fait quelques mesures, donc l'itération est environ deux fois plus rapide pour la liste, le préfixe est environ 100 fois plus rapide sur les listes, la décomposition en tête / queue est environ 10 fois plus rapide sur les listes et la génération à partir d'un objet traversable est environ 2 fois plus rapide pour les vecteurs. (C'est probablement parce que Vector peut allouer des tableaux de 32 éléments à la fois lorsque vous le créez à l'aide d'un générateur au lieu d'ajouter ou d'ajouter des éléments un par un).

Alors, quelle structure de données devrions-nous utiliser? Fondamentalement, il existe quatre cas courants:

• Nous avons seulement besoin de transformer des séquences par des opérations comme map, filter, fold etc: fondamentalement cela n'a pas d'importance, nous devons programmer notre algorithme de manière générique et pourrait même bénéficier d'accepter des séquences parallèles. Pour les opérations séquentielles, la liste est probablement un peu plus rapide. Mais vous devriez le comparer si vous devez l'optimiser.
• Nous avons besoin de beaucoup d'accès aléatoire et de mises à jour différentes, nous devons donc utiliser le vecteur, la liste sera extrêmement lente.
• Nous opérons sur les listes de manière fonctionnelle classique, en les construisant en ajoutant et en itérant par décomposition récursive: utilisez la liste, le vecteur sera plus lent d'un facteur 10-100 ou plus.
• Nous avons un algorithme critique de performance qui est fondamentalement impératif et fait beaucoup d'accès aléatoire sur une liste, quelque chose comme un tri rapide en place: utilisez une structure de données impérative, par exemple ArrayBuffer, localement et copiez vos données depuis et vers elle.

Pour les collections immuables, si vous voulez une séquence, votre décision principale est d'utiliser IndexedSeqou non LinearSeq, ce qui donne des garanties de performances différentes. Un IndexedSeq fournit un accès aléatoire rapide aux éléments et une opération de longueur rapide. Un LinearSeq fournit un accès rapide uniquement au premier élément via head, mais a également un tailfonctionnement rapide . (Tiré de la documentation Seq.)

Pour un, IndexedSeqvous choisiriez normalement un Vector. Ranges et WrappedStrings sont également IndexedSeqs.

Pour un, LinearSeqvous choisirez normalement un Listou son équivalent paresseux Stream. D'autres exemples sont Queues et Stacks.

Donc, en termes Java, ArrayListutilisé de manière similaire à Scala Vector, et de LinkedListmanière similaire à Scala List. Mais dans Scala, j'aurais tendance à utiliser List plus souvent que Vector, car Scala a un bien meilleur support pour les fonctions qui incluent la traversée de la séquence, comme le mappage, le pliage, l'itération, etc. Vous aurez tendance à utiliser ces fonctions pour manipuler la liste comme un plutôt que d'accéder de manière aléatoire à des éléments individuels.

Dans les situations qui impliquent beaucoup d'accès aléatoire et de mutation aléatoire, un Vector(ou - comme le disent les docs - un Seq) semble être un bon compromis. C'est également ce que suggèrent les caractéristiques de performance .

De plus, la Vectorclasse semble bien jouer dans des environnements distribués sans beaucoup de duplication de données car il n'est pas nécessaire de faire une copie sur écriture pour l'objet complet. (Voir: http://akka.io/docs/akka/1.1.3/scala/stm.html#persistent-datastructures )

Si vous programmez immuablement et avez besoin d'un accès aléatoire, Seq est le chemin à parcourir (sauf si vous voulez un Set, ce que vous faites souvent). Sinon, List fonctionne bien, sauf que ses opérations ne peuvent pas être parallélisées.

Si vous n'avez pas besoin de structures de données immuables, restez avec ArrayBuffer car c'est l'équivalent Scala d'ArrayList.