Views are able to defer evaluation by returning a data structure that composes the previous transformation state with the next transformation. The Scala implementation of views is admittedly complicated to digest because it provides a large number of capabilities while retaining support for all Scala collections. To build an intuition for how views are implemented, let's construct our own lazily evaluated view that works only for List and only supports map operations. To begin, we define the operations that are supported by our implementation of a PseudoView view:

sealed trait PseudoView[A] { 
  def map[B](f: A => B): PseudoView[B] 
  def toList: List[A] 
} 

The PseudoView is defined as a trait that supports lazy application of a transformation from A to B and also supports evaluating all transformations to return a List. Next, we define two view types of view to support the initial case when zero transformations have been applied and to support applying a transformation to a previously transformed view. The signatures are shown in the following snippet:

final class InitialView[A](xs: List[A]) extends PseudoView[A] 
final class ComposedView[A, B](xs: List[A], fa: A => B) extends PseudoView[B] 

In both scenarios, the original List must be carried through to support eventually applying the transformations. In the InitialView base case, there are zero transformations, which is why there is no additional state. ComposedView supports chaining computations by carrying the state of the previous fa transformation.

Implementing InitialView is a straightforward delegation to ComposedView:

final class InitialView[A](xs: List[A]) extends PseudoView[A] { 
  def map[B](f: A => B): PseudoView[B] = new ComposedView[A, B](xs, f) 
  def toList: List[A] = xs 
} 

The List implementation shows how transformations are chained together using function composition:

final class ComposedView[A, B](xs: List[A], fa: A => B) extends PseudoView[B] { 
  def map[C](f: B => C): PseudoView[C] = new ComposedView(xs, f.compose(fa)) 
  def toList: List[B] = xs.map(fa) 
} 

Let's construct a PseudoView companion object that provides view construction, as follows:

object PseudoView {  
  def view[A, B](xs: List[A]): PseudoView[A] = new InitialView(xs) 
} 

We can now exercise PseudoView with a simple program to demonstrate that it defers evaluation:

println("PseudoView evaluation:") 
val listPseudoView = PseudoView.view(List(0, 1, 2)).map(i => { 
  println(s"Adding one to $i") 
  i + 1 
}).map(i => { 
  println(s"Multiplying $i") 
  i * 2 
}) 
 
println("--- Converting PseudoView to List ---") 
println(listPseudoView.toList) 

Running this program, we see output equivalent to usage of Scala's view implementation:

PseudoView evaluation: 
--- Converting PseudoView to List --- 
Adding one to 0 
Multiplying 1 
Adding one to 1 
Multiplying 2 
Adding one to 2 
Multiplying 3 
List(2, 4, 6) 

PseudoView helps build an intuition about how Scala implements views. From here, you can begin considering how to support other operations. For example, how can filter be implemented? The filter is interesting to consider because it constrains the original collection. As defined, PseudoView is ill-equipped to support the filter operations, which is one illustration of the complexity that is handled by Scala views. Scala views tackles this challenge by defining a trait named Transformed. The Transformed trait is the base trait for all view operations. A partial definition is shown, as follows:

trait Transformed[+B] extends GenTraversableView[B, Coll] { 
  def foreach[U](f: B => U): Unit 
  lazy val underlying = self.underlying 
} 

The underlying lazy value is how the originally wrapped collection is accessed. This is analogous to how PseudoView passed the List state into ComposedView. Transformed defines a side-effecting foreach operation to support collection operations in a lazy manner. Using foreach allows implementations of this trait to modify the underlying collection. This is how filter is implemented:

trait Filtered extends Transformed[A] { 
  protected[this] val pred: A => Boolean 
  def foreach[U](f: A => U) { 
    for (x <- self) 
      if (pred(x)) f(x) 
  } 
} 

Transformed is used within the view API to maintain the state of necessary operations, while the external API supports interacting with SeqView. Following another pattern that is commonly found in Scala collections, SeqView inherits a number of operations by mixing in other traits. SeqView indirectly mixes in TraversableViewLike, which provides access to the Transformed operations.

With our newly-developed intuition for views, we may view (no pun intended!) the construction of performance trend reports differently. Scala's implementation of views makes it trivial to switch from eagerly evaluated collections to a lazily evaluated version. If you recall, once the order ID to the average execution price lookup table is constructed, a series of transformations are applied to the orders that are retrieved for the duration and ticker. By converting orders to a view, there is an opportunity to avoid unnecessary transformations and improve the speed of the performance trend report.

While it is trivial to convert to a view, it is less trivial to identify under which conditions lazy evaluation out-performs eager evaluation. As a good performance engineer, you want to benchmark your proposed change, but you do not have access to historical order and execution data to build a benchmark. Instead, you write a microbenchmark that simulates the problem that you are modeling. The question that you are trying to answer is, "For what size collection and what number of operations does it make sense to use a view over a List?" There is a cost to constructing a view because it involves retaining information about the deferred transformation, which implies it will not always be the most performant solution. You come up with the following scenarios to help answer your question:

  @Benchmark 
  def singleTransformList(state: ViewState): List[Int] = 
    state.numbers.map(_ * 2) 
 
  @Benchmark 
  def singleTransformView(state: ViewState): Vector[Int] = 
    state.numbers.view.map(_ * 2).toVector 
 
  @Benchmark 
  def twoTransformsList(state: ViewState): List[Int] = 
    state.numbers.map(_ * 2).filter(_ % 3 == 0) 
 
  @Benchmark 
  def twoTransformsView(state: ViewState): Vector[Int] = 
    state.numbers.view.map(_ * 2).filter(_ % 3 == 0).toVector 
 
  @Benchmark 
  def threeTransformsList(state: ViewState): List[Int] = 
    state.numbers.map(_ * 2).map(_ + 7).filter(_ % 3 == 0) 
 
  @Benchmark 
  def threeTransformsView(state: ViewState): Vector[Int] = 
    state.numbers.view.map(_ * 2).map(_ + 7).filter(_ % 3 == 0).toVector 

For each collection type, a List, and a view over a Vector, you define three tests that exercise an increasing number of transformations. Vector is used instead of List because toList on a view is not specialized for List. As we have previously seen, List operations are written to take advantage of constant time and prepend performance. The toList performs linear time append operations, which gives the false impression that views deliver lower performance. Switching to Vector provides effectively constant time append operations. The state for this benchmark looks like the following:

@State(Scope.Benchmark) 
class ViewState { 
 
  @Param(Array("10", "1000", "1000000")) 
  var collectionSize: Int = 0 
 
  var numbers: List[Int] = Nil 
 
  @Setup 
  def setup(): Unit = { 
    numbers = (for (i <- 1 to collectionSize) yield i).toList 
  } 
} 

ViewState sweeps different collection sizes to help identify how sensitive view performance is to collection size. The benchmark is invoked via the following:

sbt 'project chapter5' 'jmh:run ViewBenchmarks -foe true'

This invocation produces the following results:

The results give us an interesting insight into the cases where using a view yields better performance. For a small collection, such as 10 elements in our benchmark, a List performs better, regardless of the amount of operations, although this gap closes at 1,000,000 elements. When transforming a large collection, 1,000,000 elements in our benchmark, a view is more efficient with an increasing differential as the number of transformations increases. For example, with 1,000,000 elements and two transformations, views deliver approximately triple the throughput of List. In the case of a medium size collection, such as 1,000 elements in this example, this is not as clear-cut. When performing a single transformation, an eager List performs better, while a view delivers better throughput when applying more than one transformation.

As the volume of your data and the transformation count increase, it becomes more likely that a view offers better performance. Here, you see the tangible benefit of avoiding intermediate collections. A second axis of performance to consider is the nature of the transformation. Transformations that benefit from early termination (for example, find), benefit strongly from lazy evaluation. This benchmark illustrates that it is important to understand the size of your data and the transformations that you intend to perform.

As views mirror the collection API, it can be a challenge to identify when transformations are being applied lazily. For this reason, we recommend setting well-defined boundaries for view usage. When working on client reporting, we limited view usage to a single inner-function and used a List eager collection type as the return type. Minimizing the area of a system performing a lazy evaluation can reduce cognitive load when building a runtime execution mental model.

On a related note, we feel that it is important to be cautious about how a view is transformed into an eagerly evaluated collection type. We showed conversion by invoking toList, which makes the intent explicit. SeqView also provides a force method to force evaluation. As a general rule, we avoid using force because it typically returns scala.collection.immutable.Seq. SeqView retains the collection type as its second generic parameter, which allows force to return the original collection type when there is enough evidence. However, certain operations, such as map, cause the view to lose evidence of the original collection type. When this happens, force returns the more general Seq collection type. Seq is a trait that is a super-type to all sequences in the collection library, including views and another lazy data structure that we will discuss later, named scala.collection.immutable.Stream. This inheritance scheme allows the following three statements to compile:

val list: Seq[Int] = List(1, 2, 3) 
val view: Seq[Int] = list.view 
val stream: Seq[Int] = list.toStream 

We believe this is undesirable because the Seq data type hides critical information about the underlying implementation. It represents both lazy and eagerly evaluated collections with the same type. Consider the following snippet example to understand why this is undesirable:

def shouldGenerateOrder(xs: Seq[Execution]): Boolean =  
  xs.size >= 3 

In this manufactured example, imagine that shouldGenerateOrder is invoked with a Vector, but then later the Vector is swapped out for SeqView. With Vector, identifying collection length is a constant time operation. With SeqView, you cannot reason with certainty about the runtime of the operation, except to say that it is definitely more expensive than Vector.size. Seq usage, and, therefore, the usage of force, should be avoided because it is difficult to reason about runtime behavior, and this can lead to unexpected side-effects.

In a typical software system, areas of responsibility are separated into discrete modules. Using the performance trend reporting example, you can imagine a separate module containing the translation from List[TradingPerformanceTrend] to a PDF report. You may be tempted to expose the view to other modules to extend the benefit of lazy transformations. If benchmarks justify making this type of change, then we encourage you to choose one of these options. Our preferred choice in this scenario is to use Stream, which is a lazily evaluated version of List. We explore Stream later in this chapter. Alternatively, if Stream cannot be used, be strict in your use of the SeqView datatype to clearly demarcate that the collection is lazily evaluated.

One additional consideration when using views is to be cognizant of when transformations are repeatedly applied. For example consider this manufactured example that focuses on a use case where a view is used as a base for multiple computations:

> val xs = List(1,2,3,4,5).view.map(x => {  println(s"multiply $x"); x * 2 }) 
xs: scala.collection.SeqView[Int,Seq[_]] = SeqViewM(...) 
> val evens = xs.filter(_ % 2 == 0).toList 
multiply 1 
multiply 2 
multiply 3 
multiply 4 
multiply 5 
evens: List[Int] = List(2, 4, 6, 8, 10) 
 
> val odds = xs.filter(_ % 2 != 0).toList 
multiply 1 
multiply 2 
multiply 3 
multiply 4 
multiply 5 
odds: List[Int] = List() 

In this example, xs is a view on a list of integers. A map transformation is lazily applied to multiply these integers by 2. The view is then used to create two List instances, one containing even elements, the other containing odd elements. We observe that the transformation is applied to the view twice, each time we turn the view into a list. This shows that the transformation is lazily applied, but the results of the computation are not cached. This is a characteristic of views to keep in mind, as expensive transformations applied several times can cause significant slowdowns. This is also the reason why side-effects should be avoided in transformations applied to views. If, for some reason, referential transparency is not upheld, the combination of side-effects and multiple evaluations due to view usage can lead to exceptionally difficult to maintain software.

This example is straightforward, and the misuse of views is easy to spot. However, even methods that are provided by the standard library can lead to undesirable results when used with views. Consider this snippet:

> val (evens, odds) = List(1,2,3,4,5).view.map(x => {  println(s"multiply $x"); x * 2 }).partition(_ % 2 == 0) 
evens: scala.collection.SeqView[Int,Seq[_]] = SeqViewMF(...) 
odds: scala.collection.SeqView[Int,Seq[_]] = SeqViewMF(...) 
 
> println(evens.toList, odds.toList) 
multiply 1 
multiply 2 
multiply 3 
multiply 4 
multiply 5 
multiply 1 
multiply 2 
multiply 3 
multiply 4 
multiply 5 
(List(2, 4, 6, 8, 10),List()) 

This example achieves the same results as the previous sample, but we rely on the built-in partition method to split the original list into two distinct collections each operating on the original view. Again, we see the map transformation applied twice to the original view. This is due to the underlying implementation of partition in TraversableViewLike. The main takeaway is that views and lazy evaluation can help yield better performance, but they should be used carefully. It is a good idea to experiment and try your algorithm in the REPL to confirm that you are using views correctly.

In our running example on reporting on trading performance trends, we saw an easy-to-miss example of lazy evaluation when operating on a Map. Recall that there was a lookup table built using the following code:

executions.groupBy(_.id).mapValues(es =>
Price.average(es.map(_.price)))

The return type of mapValues is Map[A, B], which does not suggest any difference in evaluation strategy. Let's run a simple example in the REPL:

> val m = Map("a" -> 1, "b" -> 2)
m: scala.collection.immutable.Map[String,Int] = Map(a -> 1, b -> 2)
> val m_prime = m.mapValues{ v => println(s"Mapping $v"); v * 2}
Mapping 1
Mapping 2
m_prime: scala.collection.immutable.Map[String,Int] = Map(a -> 2, b -> 4)
> m_prime.get("a")
Mapping 1
res0: Option[Int] = Some(2)
> m_prime.get("a")
Mapping 1
res1: Option[Int] = Some(2)

Notice how, each time we call get on m_prime to retrieve a value, we can observe the transformation being applied, even when using the same key. The mapValues is a lazily-evaluated transformation of each value in the map akin to a view operating on the keys of a map. The types that are involved do not provide any insight, and unless you inspect the implementation of Map or carefully read the documentation that is associated with mapValues, you will likely miss this important detail. Consider the caveats of views when working with mapValues.