Test Metro Ide Locally

Load graph data and record a refresh

Read Performance Tracing for the current capture behavior. In Settings > Tools > Metro, open Debugging/Experimental and enable Enable debugging options. Match these settings between runs:

• Analysis pool size; use 1 unless the comparison calls for another value.
• Include thread activity; leave it off for the basic timing comparison.
• Resolve bindings from compiled dependencies.
• Automatically refresh graphs and bindings after code changes.
• Automatically validate the pinned graph after code changes.

Automatic refresh and validation can add overlapping work. Set them consistently and record the chosen values. Debugging must stay enabled for the configured analysis pool size to apply.

Open View > Tool Windows > Metro. Refresh loads graph contexts across the project. The graph selector filters the displayed context and its extensions. Record the chosen context for validation and navigation checks. For a first-refresh measurement, start with Refresh with tracing before any untraced load. For a warm measurement, let the initial refresh finish before starting a capture.

For refresh timing, use More > Refresh with tracing in the Metro tool window. This menu provides the preferred accessible route. The same action is available by right-clicking Refresh and choosing Refresh with tracing. It starts recording, submits the refresh, awaits completion, saves the trace, and opens the result. Let that flow finish. It needs no manual Start/Stop actions or Refresh-button polling.

The capture creates an empty metro-ide-*.perfetto-trace in the runner's IDE log directory at startup. File existence alone does not establish completion. Wait for the automatically opened trace or a saved nonempty capture with the completion metadata below. If UI automation cannot invoke the action, resolve that interaction before continuing the timing experiment. Preserve the intended capture mode.

Run one capture at a time. Verify the previous capture's completion metadata before invoking the next refresh. Java accessibility can report popup rows as enabled while their actions are disabled, so an AX enabled value does not establish readiness. Re-read the current popup labels and confirm Refresh with tracing before selecting its row.

Require the refresh operation's outcome to be published and capture.finish to have stop_reason=completed and partial=false for a successful measured refresh. A failed refresh can finish recording normally. The 10-minute capture deadline can produce a partial trace; report it as partial. Check dropped_events too. The detail timeline holds 20,000 events. Current builds retain up to 1,024 additional enclosing/completion records separately. Earlier builds can lose those records when the detail budget fills, even when partial=false. Missing completion metadata leaves publication and elapsed time unverified. capture.overview measures retained events and cannot fill that gap.

Use Start Metro Performance Trace for operations outside an explicit refresh, such as editor navigation. Begin recording before triggering the operation. Its recording status is Tracing enabled…. It automatically ends admission after 60 seconds and saves once admitted work drains; Stop Metro Performance Trace can end admission sooner. Account for graph work that happened before recording and use the same capture mode on both sides. These captures require their own completeness checks.

Refresh being enabled only establishes that no explicit refresh remains pending. Hidden status panels retain their old text, so accessibility output can include stale progress messages. Check visible graph and binding rows as UI evidence. Confirm publication through the trace outcome.

Read refresh and indexing costs separately

In Perfetto, use debug.operation, debug.operation_id, and debug.parent_operation_id to follow operations. For Refresh with tracing, measure the enclosing refresh duration. Manual captures can contain index.candidate operations; check for outcome=published and report that narrower measurement boundary. Inspect source scanning, class resolution, cache counts, and cancellation/retry details to explain the change. Parent spans include their children. Concurrent worker durations can overlap; summed stage or item durations can exceed elapsed refresh time.

IDEA also writes indexing diagnostics under the runner log directory. Inspect indexing-diagnostic/<project>/diagnostic-*.json and the adjacent HTML report. For type == "DumbIndexing", inspect projectIndexingActivityHistory.totalStatsPerIndexer[] and identify each measured index by its ID.

Record totalNumberOfFiles, totalFilesSize, and partOfTotalIndexingTime.part / 1e6 in milliseconds. That duration accumulates indexer wall time across worker threads. The JSON also uses the legacy field name totalCpuTime; the HTML describes these measurements as wall time. Keep this accumulated work separate from times.totalWallTimeWithoutPauses and user-visible refresh latency. Shared file loading and index application overhead are separate totals. An absent entry in a warm session does not establish zero maintenance cost.

Report evidence

Provide the matched runtime/settings, source revisions and dirty state, graph, cache state, completed or partial outcome, trace paths, and indexing-report paths. Compare elapsed refresh time and relevant work counts. Verify that the expected graph and representative binding navigation still work. Describe any uncompleted import, UI-binding, or capture step explicitly. Keep accumulated indexer work and elapsed indexing duration separate when explaining a speedup.