Have you ever wondered about the performance impact of using a lazy keyword in Scala? Recently, I had a dispute with my colleagues about it. It resulted in a set of microbenchmarks with quite interesting results which I share in this article.

Before going to the benchmark results, let’s try to understand what can cause any performance penalty. For my JMH benchmark, I created a very simple Scala class with a single lazy value in it:

@State(Scope.Benchmark)
classLazyValCounterProvider {
  lazy val counter=SlowInitializer.createCounter()
}

Now, let’s take a look at what is hidden under the hood of the lazy keyword. At first, we need to compile given code with Scala and then it can be decompiled to correspondent Java code. I used JD decompiler and here is the output (I skip @ScalaSignature’s content for the sake of readability):

@State(Scope.Benchmark)
@ScalaSignature(bytes="...")
publicclassLazyValCounterProvider {
  private SlowInitializer.Counter counter;
  private volatile boolean bitmap$0;

  privateSlowInitializer.Counter counter$lzycompute() {
    synchronized(this) {
      if(!this.bitmap$0) {
        this.counter = SlowInitializer.createCounter();
        this.bitmap$0 = true;
        return this.counter;
      }
    }
  }

  public SlowInitializer.Counter counter() {
    return this.bitmap$0 ? this.counter : counter$lzycompute();
  }
}

As it’s seen, the lazy keyword is translated to a classical double-checked locking idiom for delayed initialization. Thus, most of the time, the only performance penalty may come from a single volatile read per lazy val read (except for the time it takes to initialize lazy val instance since its very first interaction). Let’s finally measure its impact in numbers.

My very simple JMH-based microbenchmark is shown below:

public class LazyValsBenchmarks {
  @Benchmark
  public long baseline(ValCounterProvider eagerProvider) {
    return eagerProvider.counter().incrementAndGet();
  }

  @Benchmark
  public long lazyValCounter(LazyValCounterProvider lazyProvider) {
    return lazyProvider.counter().incrementAndGet();
  }
}

In a baseline method, I measure the thoughput of accessing a final counter object and incrementing an integer value by 1. As we’ve just found out, the main benchmark method – lazyValCounter – also does one volatile read in addition to what the baseline method does.

Note: All measurements are performed on MBA with Core i5 1.7GHz CPU.

Benchmark results

All results are obtained with JMH running in throughput mode measuring op(s). Each JMH session contained 10 samples and lasted for 50 seconds. I performed six measurements with the following options:

The benchmark results show that the lazy performance penalty is quite small and can be ignored in most cases. Roughly speaking, the overhead is comparable with compound assignment operation time.

For further reading on the subject, I recommend SIP 20 – Improved Lazy Vals Initialization. It contains an interesting in-depth analysis of existing issues with lazy initialization implementation in Scala.