The same build takes twenty seconds on Windows and four minutes in the subsystem: is that expected?

Known, expected, and the cause is exactly what you deduced: you are crossing a filesystem boundary on every file operation.

When the project lives on the Windows drive and Linux reaches it through the mounted path, every open, stat and read goes through a translation layer between two different filesystems with different semantics. One file is fine. A dependency install touching tens of thousands of files pays that cost tens of thousands of times, which is why the slowdown scales with file count and not with work done.

It is not a misconfiguration and there is no setting that makes it fast. It is the architecture.

The fix is to keep the files on the Linux side. Move the project into your Linux home directory rather than accessing it through the mount. The same install that takes minutes across the boundary typically takes seconds natively, and the difference is not subtle.

The rule to carry: work where the tools are. Linux tooling on the Linux filesystem, Windows tooling on the Windows filesystem. The mounts exist for moving things between the two occasionally, not for living on.

Which leaves your editor, and that is the good news - see below, because you do not have to give it up.

You keep the editor. Most modern editors have a mode where the interface runs on Windows and the actual work, the language server, the terminal, the file access, the extensions: runs inside the Linux environment.

What that gets you:

Files stay on the Linux filesystem, so everything is fast.

The editor looks and behaves exactly as it does now.

The integrated terminal is a Linux shell in the right place, so you stop switching windows.

Language servers and formatters run against the Linux environment, which also fixes a whole category of subtle problems where the tooling saw different paths or a different runtime version from the one actually executing.

Setup is usually installing one extension and opening the folder from inside the Linux environment rather than through the mounted path.

One thing to watch while migrating: do not copy the project across the mount and keep working on the copy. Move it, verify, and delete the old location, or you will end up editing one and building the other, which is a confusing hour.

And if some tool genuinely must run on Windows against those files, keep that specific thing on the Windows side rather than compromising the whole project's location for it.

A few related things that catch people once the project has moved.

Access Linux files from Windows through the network path that the subsystem exposes, not by hunting for the virtual disk file. Explorer and Windows applications can read and write there. It is slower than native Windows access, which is the mirror image of your original problem, so use it for occasional access rather than for a build.

Do not edit Linux files with a Windows tool that rewrites line endings unless you have configured it. This produces a class of confusing failures where a script suddenly will not run.

Backups. People move their work into the Linux filesystem and their backup tool is only watching the Windows drive. Worth checking before you have a month of work in there.

Disk space. The virtual disk grows and does not automatically return space when you delete files, so it can consume a lot over time. There is a compaction procedure; worth knowing it exists before the drive fills.

And on your original symptom, for anyone reading later with a smaller version of it: if something is slow only when it touches many files, and only in the subsystem, it is nearly always this and the answer is nearly always to move the files.