# compose

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 ?

https://www.baeldung.com/java-measure-elapsed-time#1-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...

But must be public in the bytecode.

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

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

You can also use Composer.setTracer to hook into tracing APIs, but that's going to override default tracing tracker

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 🙂

So you can trace when composable is run and duration of that call 🙂

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.

I have used perfetto traces and macrobenchmark for wider picture of screen. Not able to understand how can we use these to measure performance of just single Composable. Say I’m building some variations of button, how can I get to know which one is performant? Place single button on blank surface and capture perfetto trace for that activity?

@Kshitij Patil You can use intent extra to have a different behaviours in an activity. Here’s an example, where am checking if Coil is better than native Image component. Hope this helps

Thanks @theapache64, this is really helpful