1

Working in Scala, I have encounter immutable items, for this example immutable.Map. There are times where code that I do not control (Spark) returns an immutable.Map that I want to process and add elements too. I am using the following approach, because it compiles and runs. I am hoping the computer is smart enough to do this efficiently, but do not believe I should make that assumption.

var map: immutable.Map[Int, Double] = getMapFromSomewhere()
var i = 0
while(i < 5){
    map += (i -> 0.0)
    i +=1
}

I am hoping that this takes my new map item, places it into memory and does not make a copy of Map, that has to be cleaned up by garbage collection. Should I be creating a mutable.Map from my immutable.Map to do these types of operations instead?

Dan Ciborowski - MSFT
  • 6,807
  • 10
  • 53
  • 88

2 Answers2

3

When you "add" to an immutable collection, you are really creating a new Collection, which ideally and usually shares the same memory and data with the old Collection. This is safe, because since the Collections are immutable, you don't need to worry that a change in one will corrupt the other.

Your code is... not so great. That's a terribly ugly style for Scala, and your types are off. (There's no such thing as "immutable.Map[Double]", since Map takes two type parameters. You are building an immutable.Map[Int,Double], I guess.)

Here's a less ugly way to build what you are trying to build:

(0 until 5).map( i => (i, 0.0) ).toMap

or, more precisely, since you may be starting with a nonempty map

getMapFromSomwhere() ++ (0 until 5).map(i =>(i, 0.0))

Reserve mutable data structures for special cases where you really need them, and use them only if you have carefully thought through how you will manage any concurrency or if you can guarantee there will be no concurrent access. Your default in Scala should be immutable datastructures built and manipulated in a functional style, avoiding explicit external iteration of the sort in your example. You should use the keyword "var" only rarely, like mutable datastructures, only for special cases you have thought through carefully.

Steve Waldman
  • 13,689
  • 1
  • 35
  • 45
  • sorry for the ugly loop, appreciate the feedback. Fixed the map in my example, was just a typo when free handing the code. Thank you for confirming the process of updating immutable does not negatively impact my memory as feared. – Dan Ciborowski - MSFT Jan 26 '18 at 04:46
1

The data structures in functional programming languages are not just simply immutable(their reference can't be changes once it is created) but also persistent. By persistent means it reuses the existing collection for some of the operations. For example, in Scala prepending an element to the list is optimized(So when you are using list, you should think append operation as kind of pushing an element to stack).

Similarly, other collections are optimized as well for other operations. I gave you few references that help you to get more understanding on persistent data structures in functional programming.

  1. Persistent data structures in Scala 2.https://www.packtpub.com/mapt/book/application_development/9781783985845/3/ch03lvl1sec25/persistent-data-structures
  2. https://www.youtube.com/watch?v=pNhBQJN44YQ
  3. https://www.youtube.com/watch?v=T0yzrZL1py0
user51
  • 8,843
  • 21
  • 79
  • 158