perf: preserve symlinks while scanning user code

[patak-dev]

Description

Testing an idea we were discussing with @bluwy. We can avoid costly realPathSync calls for user code while scanning. I haven't noticed a diff in perf though. @sapphi-red maybe when you are back to your Windows machine you could try this one?

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[patak-dev]

Interesting, one down, one up for the benchmarks https://github.com/vitejs/vite-benchmark/actions/runs/4660951837. Maybe there is something wrong with the PR, I wouldn't expect things to be slower after it.

[patak-dev]

Another run with the same result https://github.com/vitejs/vite-benchmark/actions/runs/4664331499. @fi3ework said that there could be a 1% variance that is noise though.

[bluwy]

I ran this locally with a project with many entires (git merge main first as the optimizer change seems to affect the timing), I'm seeing a small decrease of 290s to 283ms. Maybe it's more obvious on other OSes.

[fi3ework]

Ran twice on Windows (add a os inputs for workflow)

• https://github.com/vitejs/vite-benchmark/actions/runs/4670725178
• https://github.com/vitejs/vite-benchmark/actions/runs/4670954361

It shows FCP did get a perf gain 🤔.

[patak-dev]

I did 50 times run in Linux and it shows ~0.75% improvement of the 2.7-slow case, and almost no difference in the other case: https://github.com/vitejs/vite-benchmark/actions/runs/4682746568

If this is safe, it looks like a good optimization. We can also hold it until the next minor to keep stabilizing 4.3 and getting to users sooner.

[sapphi-red]

I ran the "1000 React components" benchmark on my machine with this PR.

Babel (cold start) was 4949.9ms and SWC (cold start) was 3046.5ms.
It's a 150ms - 200ms perf gain.

[sapphi-red]

I noticed that the scanner uses the same Package Cache with the normal pipeline. So the scanner's preserveSymlinks: true result might pollute the Package Cache. Then, the normal pipeline will resolve the path with preserveSymlinks: true when we expect the path to be resolved with preserveSymlinks: false.

vite/packages/vite/src/node/optimizer/scan.ts

Lines 211 to 215 in f2aadb0

	const container = await createPluginContainer(config)
	if (scanContext?.cancelled) return
	const plugin = esbuildScanPlugin(config, container, deps, missing, entries)

vite/packages/vite/src/node/optimizer/scan.ts

Lines 272 to 297 in f2aadb0

	function esbuildScanPlugin(
	config: ResolvedConfig,
	container: PluginContainer,
	depImports: Record<string, string>,
	missing: Record<string, string>,
	entries: string[],
	): Plugin {
	const seen = new Map<string, string | undefined>()
	const resolve = async (
	id: string,
	importer?: string,
	options?: ResolveIdOptions,
	) => {
	const key = id + (importer && path.dirname(importer))
	if (seen.has(key)) {
	return seen.get(key)
	}
	const resolved = await container.resolveId(
	id,
	importer && normalizePath(importer),
	{
	...options,
	scan: true,
	},
	)

vite/packages/vite/src/node/plugins/index.ts

Lines 60 to 65 in f2aadb0

	resolvePlugin({
	...config.resolve,
	root: config.root,
	isProduction: config.isProduction,
	isBuild,
	packageCache: config.packageCache,

[patak-dev]

Thanks for the review @sapphi-red. I'm no longer sure about adding the extra complexity of changing preserverSymlinks for user code only, even if we could use separate package caches. Let's close this PR for now.