analyze-startup-performance

Compare the two Startup Performance reports phase-by-phase using Phase durations, not absolute mark offsets. If differences concentrate in restore-related phases like Services restored or Editors restored, the cause is likely workspace state or size rather than a code regression.

The Phases table pairs adjacent milestones from the MILESTONES list and shows their duration, while the Marks table shows absolute offsets of all marks. Adjacent pairing only works for serial milestones; parallel tasks must be compared by their Marks offsets directly.

Not directly. The git extension runs in a lazily spawned extension host after first paint. The real effect is indirect: git repos tend to be large directories, so recursive file watching and Explorer tree reads consume CPU that competes with renderer restore.

Lazy-triggered marks like extHostDidSpawn or didInitializeMonaco can land after window mount. TimerService sorts by startTime before pairing, so their neighbors in the Phases table may be misleading; check the will-to-did pair duration instead.

Add a constant to PerfMarks in marks.ts, call mark() at the emit point after awaiting the relevant lifecycle phase, and add serial boundaries to TimerService.MILESTONES. Keep parallel completion points out of MILESTONES to avoid mis-pairing.

Vite dev transforms modules on demand and loads the renderer module graph over HTTP, adding structural cost to bootstrap. After changing optimizeDeps.include, the first two runs rebuild caches and run slower; measure from the third run for stable numbers.