Bug

In the performance view's startup metrics table, the "blocking startup" count double-counts LifecyclePhase.Starting and omits LifecyclePhase.Ready contributions.

Current code

// Line 218 in perfviewEditor.ts
`${(contribTimings.get(LifecyclePhase.Starting)?.length ?? 0) + (contribTimings.get(LifecyclePhase.Starting)?.length ?? 0)} blocking startup`

LifecyclePhase.Starting is used for both operands. The second should be LifecyclePhase.Ready.

Evidence

The correct pattern appears later in the same file in _addWorkbenchContributionsPerfMarksTable() (lines 279-280), which correctly lists both blocking phases:

md.li(`Total (LifecyclePhase.Starting): ${timings.get(LifecyclePhase.Starting)?.length} ...`);
md.li(`Total (LifecyclePhase.Ready): ${timings.get(LifecyclePhase.Ready)?.length} ...`);

The same method's perf marks filter also confirms both phases 1 (Starting) and 2 (Ready) are "blocking":

e.name.startsWith('code/willCreateWorkbenchContribution/1') ||  // Starting
e.name.startsWith('code/didCreateWorkbenchContribution/1') ||
e.name.startsWith('code/willCreateWorkbenchContribution/2') ||  // Ready
e.name.startsWith('code/didCreateWorkbenchContribution/2')

Impact

The "blocking startup" count shown in the performance view (Developer: Startup Performance) is incorrect -- it doubles the Starting phase count and misses all Ready phase contributions.

Location

• File: src/vs/workbench/contrib/performance/browser/perfviewEditor.ts, line 218

Fix

Change the second LifecyclePhase.Starting to LifecyclePhase.Ready:

`${(contribTimings.get(LifecyclePhase.Starting)?.length ?? 0) + (contribTimings.get(LifecyclePhase.Ready)?.length ?? 0)} blocking startup`