Proposal: Optimizing Debug Report engine performance via buffered/deferred event callbacks

[vibhor1102]

Note

This suggestion is purely AI-assisted/generated. I do not have a deep in-depth understanding of the codebase's architecture myself, but I wanted to share these findings as the CPU savings during debugging sessions could be quite substantial!

Hi @Nain57,

I hope you're doing well! I've been looking into the resource and battery consumption of the app, specifically during scenario execution when debug report generation is active.

Currently, ScenarioProcessor continuously streams progress and condition callbacks (onEventsListProcessingStarted, onEventProcessingStarted, onScreenConditionProcessingCompleted, etc.) to the DebugEngine on every single frame and condition evaluation. In turn, DebugEngine launches a coroutine (coroutineScopeIo.launch) on its single-threaded IO dispatcher for each callback to track these metrics in memory (e.g., in ScreenConditionOccurrenceRecorder).

While the actual disk write (writeEventOccurrenceToReport) is already perfectly optimized to only trigger when an event successfully matches and runs its actions, the continuous stream of callbacks on non-matching frames creates a substantial amount of CPU overhead, coroutine context-switching, and object allocation/GC pressure under high-FPS scenario execution.

I wanted to ask if you think it's possible and viable to optimize this by buffering the results locally inside ScenarioProcessor during the frame loop.

Specifically:

• Keep condition/event matching results in transient local variables within the processor.
• If the event fails to match, discard them silently (avoiding any callbacks or coroutine launches).
• If the event matches and actions are executed, send the entire batch of results to the DebugEngine in a single combined callback (e.g., onEventMatched(event, results)).

Would this be viable within the architecture of the report engine? I'd love to hear your thoughts on whether this is something worth looking into or if there are architectural reasons to keep the live event stream as is.

[vibhor1102]

Restored back after a month of invisibility as my account was false-positively flagged