IssueTracker

What would you like the metric to display? the amount of time spent in composition, or number of times something composes? You can now write a custom TraceMetric that does this in the latest alphas of macrobench:

// warning - copied/pasted and edited, hasn't been tested
object : TraceMetric() {
    override fun getResult(
        captureInfo: CaptureInfo,
        traceSession: PerfettoTraceProcessor.Session
    ): List<Measurement> {
        val durationsNs = traceSession.query(
            """
                SELECT * FROM slice
                    INNER JOIN thread_track on slice.track_id = thread_track.id
                    INNER JOIN thread USING(utid)
                    INNER JOIN process USING(upid)
                WHERE process.name LIKE "${captureInfo.targetPackageName}"
                    AND slice.name LIKE "com.myapp.Item (%)"
            """.trimIndent()
        ).map { it.long("dur") }

        return listOf(
            Measurement("RecomposeItemDurNs", durations.sumOf { it } / 1_000_000.0) // convert ns -> ms
            Measurement("RecomposeItemCount", durations.size * 1.0)
        )
    }
}

Note that for this to work, you'll need to pass the instrumentation argument that enables recomposition tracing capture:

https://developer.android.com/topic/performance/benchmarking/macrobenchmark-instrumentation-args#fulltracing

If this sort of thing is generally useful, we could definitely add it to the library.

That seems to work nicely

https://github.com/google/horologist/pull/1299/files

MarqueeBenchmark_noMarquee
CanvasRecomposeCount   min    55.0,   median    55.0,   max    55.0
CanvasRecomposeDurMs   min     8.3,   median     8.3,   max     8.3

Just a question -- this looks (almost) exactly the same as TraceSectionMetric with Mode.Sum. Could we consider extending that to also have the count value?

This is pretty cool and no doubt useful. Part of me wonders if this is something we actually want to add though, aren't you testing internal Compose details at this point?

If you already have a benchmark set up, isn't frame timing and startup time a better actual metric to track than recomposition count? Hypothetically, Compose could make a behaviour change to the rules for recomposition and then your test could be marked as regressed on composition count but not on actual frame timing.

I don't think composition count counts as implementation detail though; and more importantly this is a very stable metric when compared to frame timing.

Definitely worth pursuing.

+1 to the Mode.Count idea, which makes this much easier to setup without clearly pushing people in that direction.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.benchmark:benchmark-macro:1.2.0-alpha16