skip to content

measureTime & measureTimedValue

3 roadmaps5 questions

measureTime returns how long a block took and measureTimedValue returns both the result and the elapsed time, both using a monotonic clock. Using a monotonic source rather than wall-clock time is the detail that makes the measurement trustworthy.

part ofKotlinoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What does Kotlin's measureTime { } do, and how is it different from measureTimedValue { }?

level: juniorimportance: must knowfreq 55%

answer

  1. measureTime -> Duration only
  2. measureTimedValue -> TimedValue<T>(value, duration)
  3. TimedValue is a destructurable data class
  4. Both are inline, in kotlin.time
  5. Built on a monotonic clock

basics

~10 s

measureTime runs a block and gives back how long it took as a Duration. measureTimedValue runs a block and gives back both the block's result and how long it took, packaged together.

solid answer

~40 s

Both are inline functions in kotlin.time used to time a block of code. measureTime { ... } executes the lambda and returns a Duration — the elapsed time only; the block's own return value is discarded. measureTimedValue { ... } returns a TimedValue<T>, a small data class with two properties: value (the block's result of type T) and duration (the elapsed Duration). Use measureTime when you only care about timing (e.g., logging how long something took); use measureTimedValue when you need the computed result AND its timing, so you don't have to compute or store it separately. Both rely on a monotonic clock under the hood, so they measure true elapsed time rather than wall-clock differences. Example: val (result, took) = measureTimedValue { expensiveCompute() }.

code

kotlin · 11 lines
kotlin
import kotlin.time.measureTime
import kotlin.time.measureTimedValue

val onlyTime = measureTime { Thread.sleep(50) }
println(onlyTime) // ~50ms, no result

val timed = measureTimedValue { (1..1_000).sum() }
println(timed.value)    // 500500
println(timed.duration) // e.g. 12.us

val (sum, took) = measureTimedValue { (1..1_000).sum() }

go deeper

for a junior

Knows measureTime returns a Duration and measureTimedValue also returns the result.

for a middle

Explains TimedValue<T> fields, destructuring, and when to pick each function.

for a senior

Notes inline nature, the kotlin.time package, and the monotonic clock backing both.

for a principal

Frames these as the idiomatic replacement for ad-hoc System.nanoTime() timing and discusses Duration as a first-class measurement type.

## What these functions are `measureTime` and `measureTimedValue` are top-level **inline** functions in the `kotlin.time` package. They time how long a block of code takes to run. - **Duration** — a Kotlin type representing an amount of elapsed time (e.g. `1.5.seconds`, `300.milliseconds`). It is not a clock reading; it is a length of time. - **inline** — the compiler copies the function body into the call site, so there is essentially no overhead from the lambda and no extra object allocation just to time the block. ## measureTime ```kotlin import kotlin.time.measureTime val elapsed: Duration = measureTime { doSomeWork() // the lambda's own return value is ignored } println(elapsed) // e.g. 42.3ms ``` It runs the lambda, returns the elapsed `Duration`, and **throws away** whatever the lambda returned. Use it when you only want the timing. ## measureTimedValue ```kotlin import kotlin.time.measureTimedValue val timed = measureTimedValue { computeAnswer() } println(timed.value) // the computeAnswer() result println(timed.duration) // how long it took, a Duration ``` It returns a **`TimedValue<T>`** — a small `data class` holding: - `value: T` — the result of the block - `duration: Duration` — the elapsed time Because it is a `data class`, you can destructure it: ```kotlin val (answer, took) = measureTimedValue { computeAnswer() } ``` ## Why two functions If you used `measureTime` but also needed the result, you would have to store the result in a `var` from inside the lambda — awkward. `measureTimedValue` solves that by returning both together. Choose `measureTime` for pure timing, `measureTimedValue` when the result matters too. ## Monotonic clock Both measure against a **monotonic** time source (steadily increasing, immune to wall-clock adjustments), so daylight-saving changes or NTP corrections cannot make a measured duration negative or jumpy.

  • What is the type returned by measureTimedValue?
    TimedValue<T>, a data class with a value: T property and a duration: Duration property; it can be destructured.
  • Which package are these in?
    kotlin.time.

measureTime is a stopwatch that only tells you the time; measureTimedValue is a stopwatch that also hands you the thing you were timing yourself doing.

saying these in an interview costs you the question

  • Saying measureTime returns the block's result (it returns a Duration)
  • Thinking measureTimedValue returns a Long of milliseconds
  • Claiming you must use System.currentTimeMillis() to get the result and timing
  • Not knowing TimedValue can be destructured

context

resolving links…

open as a page

Because measureTime and measureTimedValue are inline, what does that mean for using non-local return, suspend calls, and timing accuracy inside the block?

level: middleimportance: should knowfreq 35%

basics

~20 s

Because the block is inlined, you can call suspend functions inside it and even return from the surrounding function. The timing is the real time the block ran, including any suspension or blocking that happens.

open as a page

Why do measureTime / measureTimedValue use a monotonic clock instead of System.currentTimeMillis(), and what could go wrong if you timed code with wall-clock time?

level: middleimportance: should knowfreq 45%

basics

~20 s

A monotonic clock only moves forward at a steady pace, so it gives correct elapsed times. Wall-clock time can jump backward or forward (clock adjustments), which can make a measured duration wrong or even negative.

open as a page

How can you make code that uses measureTime / measureTimedValue deterministic in tests, and what role does a custom TimeSource play?

level: seniorimportance: should knowfreq 25%

basics

~20 s

The plain measureTime always uses the real clock, so it is hard to test. Instead, call measureTime on a TimeSource you control — like TestTimeSource — and advance it manually, so the measured duration is exactly what you set.

open as a page

You want to time many small operations and aggregate their durations (e.g., total and average per call). Show how measureTimedValue and Duration arithmetic support this, and what pitfalls to avoid.

level: seniorimportance: nice to knowfreq 18%

basics

~20 s

Wrap each operation in measureTimedValue to get its result and time, then add the durations together. Duration supports +, division by a number, and comparison, so totals and averages are easy. Avoid calling these in extremely hot inner loops where even small overhead matters.

open as a page