Scala Производительность потоков

Канонический пример полезности рекурсивных алгебраических типов данных и ленивая оценка - игровой алгоритм, например. как показано в знаменитой газете WhyFP Джона Хьюза (Comp. J., том 32, № 2, 1989).

Внедряя его с помощью Scala, и используя лениво оцениваемое Stream[Tree[A]] для каждого поддерева игры приводит к trait Tree[A] с определением:

sealed trait Tree[A]
case class Branch[A](ts: Stream[Tree[A]]) extends Tree[A]
case class Leaf[A](a: A) extends Tree[A]

Теперь лениво оцениваемая, возможно бесконечная игра может быть представлена как:

gameTree(b: Board): Tree[Board] = 
  if (b.isAtEndPos) Leaf(b) 
  else Branch(b.emptySlots.toStream.map((pos: Int) => gameTree(b addTic pos)))

и вы можете реализовать стратегию обрезки, оценки и распараллеливания фактический алгоритм, то есть, например, минимакс, который выполняет задание, и оценивает необходимые части дерева:

def maximize(tree: Tree[Board]): Int = tree match {
  case Leaf(board) => board.score
  case Branch(subgames) => 
     subgames.map((tree: Tree[Board]) => minimize(tree)).max
} ...
def minimize // symmetrically

Тем не менее, бесконечный поток вводит значительное снижение производительности, а решение идентичного игрового дерева с использованием списка желаний (ts: List[Tree[A]]) в 25 раз более эффективно.

Можно ли эффективно использовать потоки или ленивые структуры в Scala в подобных ситуациях?

Изменить: добавлены некоторые результаты производительности и фактический код: В является ленивой версией.

Ленивая версия (scala 2.9.1): Time for gametree creation: 0.031s and for finding the solution 133.216s.

Никаких преобразований в создании дерева, т.е. сопоставления множеств в минимаксном Time for gametree creation: 4.791s and for finding the solution 6.088s.

Преобразование в список в создании игры Time for gametree creation: 4.438s and for finding the solution 5.601s.

Ответ 1