Performance issues

[nicolasthemmer-aaa]

Hey @patrickmichalik

I currently have massive performance issues with a fairly simple graph:

The x axis represents minutes of the day (1440 values). I am drawing the chart with getXStep = { 60f * 6 } .

Especially with older devices but also with newer ones, displaying these charts takes a long time. While debugging I realized, that drawBackgroundLine is really slow

So I set backgroundShader = null. This makes it better but still not optimal. Reducing the dataset to half the points (~700 values) also increases performance but neither options are viable solutions for me.

Do you have any idea how I could increase the performance?

import kotlinx.datetime.LocalTime

private const val X_MIN = 0
private const val Y_MIN = 0
private const val Y_MAX = 1

internal val LocalTime.Companion.MAX_CLIMATIX_VALUE: LocalTime
    get() = LocalTime(23, 59)
public fun LocalTime.toMinuteOfDay(): Int = toSecondOfDay() / 60
public fun LocalTime.Companion.fromMinuteOfDay(minuteOfDay: Int): LocalTime =
    fromSecondOfDay(minuteOfDay * 60)
public val MINUTE_OF_DAY_MAX_CLIMATIX_VALUE: Int = LocalTime.MAX_CLIMATIX_VALUE.toMinuteOfDay()

@Immutable
public data class ActiveTimeSlot(
    val startMinuteOfDay: Int,
    val endMinuteOfDay: Int,
)

@Composable
fun AppScheduleChart(
    modifier: Modifier = Modifier,
) {
    val activeTimeSlots = persistentListOf(
          ActiveTimeSlot(
              startMinuteOfDay = 150,
              endMinuteOfDay = 300,
          ),
          ActiveTimeSlot(
              startMinuteOfDay = 500,
              endMinuteOfDay = 560,
          ),
          ActiveTimeSlot(
              startMinuteOfDay = 800,
              endMinuteOfDay = 1429,
          ),
      )
    
    val yValues = List(MINUTE_OF_DAY_MAX_CLIMATIX_VALUE) { Y_MIN }.toMutableList()
    val xValues = (0 until MINUTE_OF_DAY_MAX_CLIMATIX_VALUE).toList()
    activeTimeSlots.forEach {
        for (i in it.startMinuteOfDay..it.endMinuteOfDay) {
            yValues[i] = Y_MAX
        }
    }
    
    val modelProducer = remember { CartesianChartModelProducer.build() }
    LaunchedEffect(Unit) {
        withContext(Dispatchers.Default) {
            modelProducer.tryRunTransaction {
                lineSeries {
                    series(xValues, yValues)
                }
            }
        }
    }
    
    CartesianChartHost(
            // 6 hour steps (in minutes)
            getXStep = { 60f * 6 },
            chart = rememberCartesianChart(
                rememberLineCartesianLayer(
                    lines = listOf(
                        rememberLineSpec(
                            shader = DynamicShader.color(Color(0xFF595959)),
                            thickness = 1f.dp,
                        ),
                    ),
                    axisValueOverrider = remember {
                        AxisValueOverrider.fixed(
                            minY = 0f,
                            maxY = 1f,
                            minX = 0f,
                            maxX = 1440f,
                        )
                    },
                ),
            ),
            modelProducer = modelProducer,
            scrollState = rememberVicoScrollState(scrollEnabled = false),
            zoomState = rememberVicoZoomState(zoomEnabled = false),
            modifier = modifier,
     )
}

Note that I was migrating this chart from 1.14.0 to vico2. With the old version it was running smoothly

[Gowsky]

Hello @Salocin808, can you provide a MRE that is self-contained? The code you shared contains references that are unknown.

[nicolasthemmer-aaa]

Hey @Gowsky,
I edited the code to be a self contained MRE. Thanks for the help!

[nicolasthemmer-aaa]

I fixed this issue by downsampling my data and adapting the x axis accordingly.

private const val DOWN_SAMPLING_FACTOR = 5

private fun downsampleData(data: MutableList<Int>): List<Int> {
    return data.chunked(DOWN_SAMPLING_FACTOR).map { chunk ->
        val average = chunk.average()
        if (average >= 0.5) 1 else 0 
    }
}

@Composable
fun AppScheduleChart(
    activeTimeSlots: ImmutableList<ActiveTimeSlot>,
    modifier: Modifier = Modifier,
) {
    val yValues = List(MINUTE_OF_DAY_MAX_CLIMATIX_VALUE) { Y_MIN }.toMutableList()
    val xValues = (0 until (MINUTE_OF_DAY_MAX_CLIMATIX_VALUE / DOWN_SAMPLING_FACTOR)).toList()
    activeTimeSlots.forEach {
        for (i in it.startMinuteOfDay..it.endMinuteOfDay) {
            yValues[i] = Y_MAX
        }
    }

    val modelProducer = remember { CartesianChartModelProducer.build() }
    LaunchedEffect(activeTimeSlots) {
        withContext(Dispatchers.Default) {
            modelProducer.tryRunTransaction {
                lineSeries {
                    series(xValues, downsampleData(yValues))
                }
            }
        }
    }

    Chart(modelProducer = modelProducer, modifier = modifier)
}

Now I have 288 values instead of 1440 and everything runs smoothly.

I still wonder why the previous vico version was able to handle it though. In any case, this works for me. But its definately worth looking into for you guys.

[patrickmichalik]

Hello! We’re glad to hear that you’ve found a solution. We’ll certainly look into this and run some performance measurements and comparisons. I’d like to share two observations in the meantime:

1. The point count is quite large. For example, to draw the line from the chart in the image above, you need only six or ten points, not 288 or 1,440. The six-point solution would require an appropriate LineCartesianLayer.LineSpec.PointConnector, but it would let you draw perfectly vertical lines on switches from y = 0 to y = 1, which may be desired. More generally, edge cases aside, if activeTimeSlots has n elements, then 2n + 2 or 4n + 2 points are required, depending on the solution used. Adding only the required points would speed up both the chart and the data-generating logic, as there would be no large lists to iterate. In addition, unlike downsampling, this approach would leave the chart’s precision unaffected. Could you let us know the reason for the large number of points, which, for the chart above, even with downsampling, is still 28.8 or 48 times the natural point count? (I can see this being used as a workaround to change the behavior of several features, but that doesn’t seem to be the case here, and neither is it recommended.)
2. The data-generating logic runs on the main thread on every AppScheduleChart recomposition. This should be avoided. The logic could instead be placed in the withContext(Dispatchers.Default) lambda, where it would run without blocking the main thread and only when activeTimeSlots changes. This has the potential to improve performance, but it’s far less significant than point 1.

[Gowsky]

We're closing this in favour of #1025. Please note that @patrickmichalik's comment indicates the key issue in this case. Fixing the problems mentioned there should address any performance issues.