How costly is it to create(or copy) an object? - scala

Question

Considering this simple example:
trait A { def a: String = "a"; def a2: String }
case class C(b: String, c: String) extends A {
val a2 = "a2"
}
val c = C("b", "")
val copy = c.copy(c="c")
When I update field c with .copy(c="c"), are other fields(a,a2 and b) copied? Event though only their references are copied, if I have a huge hierarchy tree, will .copy become very costly?
Similarly:
class Foo {
val list = List(1,2,3,4,5,6)
}
val foo1 = new Foo
val foo2 = new Foo
Do foo1 and foo2 share an instance of List, or every time I instantiate a Foo it creates a new List? What if list is a var instead of val?

Answer 1

Generally Scala is immutable, you usually have to handle mutable cases yourself. Also case classes are immutable by nature and their copy method is generated by the compiler. So yes, they would share the same object reference. This is one of the reasons immutability is nice.
Your second question is a bit different. In that case the classes are constructed one after the other in seperate contexts.
It's also a good idea to check what's being compiled:
>scalac -print test.scala
[[syntax trees at end of cleanup]] // test.scala
package test {
class Foo extends Object {
private[this] val list: List = _;
<stable> <accessor> def list(): List = Foo.this.list;
def <init>(): b.Foo = {
Foo.super.<init>();
Foo.this.list = immutable.this.List.apply(scala.this.Predef.wrapIntArray(Array[Int]{1, 2, 3, 4, 5, 6}));
()
}
}
}
From this we can see Scala creating a new list each time. Changing this to var won't change anything, we can check:
>scalac -print test.scala
[[syntax trees at end of cleanup]] // test.scala
package test {
class Foo extends Object {
private[this] var list: List = _;
<accessor> def list(): List = Foo.this.list;
<accessor> def list_=(x$1: List): Unit = Foo.this.list = x$1;
def <init>(): b.Foo = {
Foo.super.<init>();
Foo.this.list = immutable.this.List.apply(scala.this.Predef.wrapIntArray(Array[Int]{1, 2, 3, 4, 5, 6}));
()
}
}
}
It only generated a setter method for it (def list_=(x$1: List)).
If you would like to reference the same list in both cases then initialize it with an object's default list:
object Foo {
val DefaultList = List(1,2,3,4,5,6)
}
class Foo {
var list = Foo.DefaultList
}
Which compiles to the following:
>scalac -print test.scala
[[syntax trees at end of cleanup]] // test.scala
package test {
object Foo extends Object {
private[this] val DefaultList: List = _;
<stable> <accessor> def DefaultList(): List = Foo.this.DefaultList;
def <init>(): test.Foo.type = {
Foo.super.<init>();
Foo.this.DefaultList = immutable.this.List.apply(scala.this.Predef.wrapIntArray(Array[Int]{1, 2, 3, 4, 5, 6}));
()
}
};
class Foo extends Object {
private[this] var list: List = _;
<accessor> def list(): List = Foo.this.list;
<accessor> def list_=(x$1: List): Unit = Foo.this.list = x$1;
def <init>(): test.Foo = {
Foo.super.<init>();
Foo.this.list = Foo.DefaultList();
()
}
}
}
As you can see the list is only created once and then the reference through the def DefaultList(): List assigned on each Foo class instantiation.

Answer 2

To answer my own first question:
The concrete vals in a trait are implemented as a Java static method:
// scala
trait A { def a: String = "a"; }
// java
public static java.lang.String a(A);
Code:
0: ldc #8 // String a
2: areturn
Of course, a static method can't be copied. So I don't need to worry about huge hierarchy tree.
The abstract val is implemented as a hard-coded constant:
// scala
trait B { def b: String }
case class C() { def b = "b" }
// java
public java.lang.String b();
Code:
0: ldc #47 // String b
2: areturn
It's fine as well.
The only thing(s) will be copied when I call .copy() are the fields in constructor parameter list.