configuration: batch initial policy definitions

[Dmitriy Vasyura (dmitrivMS)]

Summary

• submit regular and excluded policy definitions in one initialization batch
• avoid rebuilding the native policy watcher for a second changed batch
• add coverage that verifies included and excluded definitions reach one underlying policy update

Root cause

While profiling Agents Window startup, the main process appeared to spend 40-50 ms reading state, loading settings, and creating required directories. Direct fs/promises measurements against the same signed-in profile showed that the actual operations are fast:

Operation	Median	p95
Concurrent startup I/O group	1.02 ms	1.41 ms
Read 3.6 KB storage.json	1.02 ms	1.30 ms
Read missing settings.json	0.13 ms	0.32 ms
Existing-directory mkdir({ recursive: true })	0.62-0.76 ms	0.83-1.18 ms

The callbacks were delayed together because PolicyConfiguration.initialize() submitted definitions in two sequential groups:

1. regular/default configuration policies
2. excluded/internal configuration policies

AbstractPolicyService merges each changed group and invokes the native implementation. NativePolicyService therefore imported/updated the policy watcher for the first group, then disposed and recreated it for the second group before startup I/O callbacks could run.

This change combines both key sets before resolving and submitting policy definitions. The resulting policy model is unchanged, but native watcher initialization happens once.

Instrumented startup impact

Three warmed packaged launches per variant, using the same Windows x64 Insiders runtime and signed-in isolated profile:

Operation	Before median	After median	Change
Policy initialization	45 ms	33 ms	-12 ms
State read callback	50 ms	40 ms	-10 ms
Missing settings callback	27 ms	17 ms	-10 ms
Required-directory callbacks	46 ms	38 ms	-8 ms

The callback improvements overlap; they are not additive. They show that removing the redundant watcher update frees the main event loop sooner.

The remaining combined policy segment spends approximately 27 ms importing @vscode/policy-watcher and 6 ms creating the watcher. #334769 independently targets the packaged ESM resolution work in that import.

End-to-end A/B

The first 30 alternating paired launches measured spawn to renderer code/didStartWorkbench:

• baseline median: 1,330.31 ms
• change median: 1,326.40 ms
• median paired difference: -6.01 ms
• mean paired difference: -4.03 ms
• approximate 95% interval: -9.71 to +1.66 ms

A second 30-pair batch had a system disturbance around pairs 42-47. Across all 60 pairs, excluding five pairs where either launch exceeded 1,450 ms:

• included pairs: 55
• median paired difference: -3.03 ms
• mean paired difference: -1.96 ms
• approximate 95% interval: -5.76 to +1.83 ms

The end-to-end result is directional, not statistically significant. The deterministic result is one fewer native watcher build and an 8-12 ms reduction in the blocking initialization segment.

Compatibility

The previous initialization called update() twice before registering policy-change listeners. The new initialization calls it once with the union of the same configuration keys. Existing behavior remains covered for:

• regular policy values
• excluded/internal policy values
• owning policies and references
• late owner registration
• owner deregistration fallback
• policy updates and removals

Validation

• targeted ESLint
• npm run transpile-client
• focused PolicyConfiguration suite: 23 passing
• minified NLS desktop bundle
• instrumentation-free signed-in Agents Window product smoke
• git diff --check

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.