is it okay to measure composition time like this?

Never use

System.currentTimeMillis()

to measure elapsed time. Use

System.nanoTime()

or

SystemClock.elapsedRealtime()

on Android.

Even then, there's a lot of stuff going on during recomposition that I don't think is executed then 🤔 I doubt this measures rendering time

Yeah this only measures the time of composition phase in the three phases.

Sure. am not trying to measure

doFrame

call here anyway. but what’s the issue with

currentTimeMillis

?

Thanks 🙇 updated

@Composable
inline fun MeasureComposition(
    tag: String,
    content: @Composable () -> Unit
) {
    val timestamp = System.nanoTime()
    content()
    val diff = System.nanoTime() - timestamp
    println("$tag took for recomposition: ${diff / 1_000_000}ms")
}

You could use the

measureTime

functions in Kotlin: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.time/measure-time.html

What about hooking in with the tracing APIs the compose runtime tracing uses?

aah.. good idea.. but is it possible? 🤔

Maybe library restricted...

@Ben Trengrove [G] can you please confirm the feasibility ?

This method of tracking recomposition is fine, tracing does almost the same

Cool. So

traceEventStart

will be called for each recomposition and if its shows my composable name like this, it means it got recomposed? What else we can do with this? how can i get more data? Can i get entire

doFrame

call time at the Runtime? ( I’d like to get the measure time as well).. (sorry for asking too many questions at once 😄 this API looks exciting 😬 )

It is doing exactly the same as the sample above, but wrapped with an interface 🙂

I’m not sure if it fits your need, but you could also add a trace section to your composable and use

TraceSectionMetric

from Macrobenchmark.

@mlykotom but that’ll only appear in the

.trace

file right? I am trying to get those info at runtime

Yes, that's only in a trace :/

I haven't tried them, but remember seeing these APIs, for tracing particular blocks. Mainly because macrobenchmark added them. https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:benchmar[…]/PerfettoTrace.kt?q=androidx.benchmark.perfetto.PerfettoTrace Added experimental new APIs

PerfettoTrace.record {}

and

PerfettoTraceRule

to capture Perfetto traces (also known as System Traces) as part of a test, to inspect test behavior and performance.

I’d just like to call out the giant caveat that you will have substantial variability measuring like this even on the same device. For example, the core can be underclocked to preserve battery or due to thermals. If you’re just trying to get some really rough data or look for outliers in a release sample, it’s probably okay. If you want to measure performance so that you can make improvements and verify them, you definitely want to use Macrobenchmark.