VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

Vidar Berg — Fri, 09 Jan 2026 12:20:10 GMT

It is good to hear you have found a way to improve your workflow! I have created a bug report internally that links to this thread about the slow build times and the issue with cmake being re-run even when nothing has changed in the project.

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

cellular_iot — Tue, 06 Jan 2026 14:00:27 GMT

Apologies for the slow reply —

After working for a few months with my command-line orchestrator, I renamed it from build_and_flash to west-wind — because it feels like a strong headwind for west: it adds intelligence, guardrails, and a lot of comfort to my daily nRF Connect SDK work on a Windows / WSL2 hybrid setup.

Then west-wind was my daily tool, but I was still running into some strange nRF Connect VS Code extension issues: hot CPU, (re)builds using the wrong configs, flaky debugging — the whole “why is my machine suddenly suffering?” experience. At some point I asked myself: could I build an almost full replacement for the nRF Connect extension for most of my daily work, so I can keep the official one disabled most of the time? Mainly to prevent it from turning my poor CPU fan into a glowing-red 200,000 RPM Dyson.

After a bit of prototyping, it looked very promising — and that’s how nRF Connect Lite was born. Then, after a few days of using this setup exclusively, I had a small “aha” moment: my day-to-day work more and more felt zen-like compared to the months of friction before. The machine just did what I wanted and I enjoyed the silence. A bit of back-and-forth later, the wordplay zenRF emerged: a tooling for nRF that brings calm, flow-like development back into the loop — and here we are.

If you’re curious, I can share some details.

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

cellular_iot — Thu, 25 Sep 2025 12:52:04 GMT

Thanks for pointing me to Dev Drive — that’s completely new to me! I’ll definitely give it a try.

That said, WSL2 still seems to be way faster, especially with Unix-like build chains that push lots of small files through tons of forked processes.

This benchmark even found WSL2 to be about 2× faster than Windows 11 on Dev Drive:

superuser.com/.../1825686

My go-to AI says:

Comparison: File Systems / Build Environments

Workload / Environment	Windows NTFS (Standard)	Windows Dev Drive (ReFS + Performance Mode)	Linux / WSL2 (ext4)
`git clone` large repo (100k+ files)	Slow (many small file creates, AV hooking, NTFS overhead)	~20–40% faster due to reduced AV/Indexing + more efficient ReFS	Often 2–5× faster than Windows NTFS; cheap I/O and fork
`npm install` / `pip install` (10k+ small files)	Notoriously slow on Windows (NTFS fragmentation, AV, expensive process creation)	~30% faster, but still slower than Linux	2–10× faster, ext4 + copy-on-write fork
CMake/Ninja rebuild (C++ project, 1M LOC)	Works, but many process spawns + I/O → often 5–20× slower than Linux	10–30% faster, I/O bottlenecks reduced, but process creation remains expensive	Baseline: fast, fork/exec + pipes are cheap
Large Embedded/SDK project (Zephyr, Yocto, west)	Very slow: tens of thousands of shell tools, process creation extremely costly	Slightly better (faster I/O, less AV overhead), but process creation still the bottleneck	2–20× faster (matches observed real-world results)
Antivirus/Indexing impact	Often massive, every file access scanned	Dev Drive can run AV in “Performance Mode” → minimal overhead	None (unless you explicitly install AV)
Stability / Tool support	NTFS = universally supported	ReFS: newer, some older tools/backups may not support it	ext4 = standard, rock-solid

TL;DR

Dev Drive is a real improvement on Windows: typically 10–40% faster for I/O-heavy developer workloads.
But it does not solve the architectural issue (expensive process creation, no cheap fork).
For POSIX-heavy builds (Zephyr, Yocto, SDKs), Linux/WSL2 remains unbeatable, often 2–20× faster.

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

Vidar Berg — Thu, 25 Sep 2025 07:38:31 GMT

Thank you for this update. It looks like there is some interest in your solution. Other things that may be worth checking are the antivirus configuration and setting up a dev drive (https://learn.microsoft.com/en-us/windows/dev-drive/ ).

We also need to investigate on our end why cmake is being re-run in some cases when calling west flash after having just built the project.

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

Tom_H — Wed, 24 Sep 2025 08:16:07 GMT

Hi, I’m running into a very similar issue — with a medium-large NCS project on Windows, my incremental build times are already over 2 minutes. It would really help if you could share your dev setup in detail.

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

cellular_iot — Wed, 24 Sep 2025 07:57:17 GMT

So I switched my setup to VSCode on Windows + source tree in WSL2.

Editor/Extensions: VSCode runs natively on Windows, sources and all extensions are inside Linux (WSL2).
Builds: 2 seconds on changed files, full rebuilds are now 10–20 seconds instead of ~120 seconds on Windows native.
Flashing/Debugging: Using J-Link through the WSL2 USB bridge was unstable. When I started a debug session, it flashed once, then the J-Link re-enumerated with a different VID/PID and the debugger lost the device.

Solution:
I now use my own build_and_flash.sh script:

Builds run completely inside Linux (fast).
switching between multiple VSCode configs takes a second
Flashing and debugging automagically use the Segger Windows-native tools (JLink GDB Server, RTT Viewer, etc.).

This hybrid setup sounds a bit complicated, but in practice it’s 10× faster than the Windows-only setup and 10× more reliable than the full WSL2 + USB bridge approach.

Let me know if you’d like me to share my detailed setup.

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

cellular_iot — Tue, 16 Sep 2025 14:14:30 GMT

in the meantime I try to switch to a WSl2 based nrf Connect - which seemed a good idea as long as I only had build configs - blazingly fast compared to windows native. And this morning I've observed the same effect in WSL nrf: a full build and again a full build when I tried to flash righ after.

That said - build times are the pro of WSL2 based setup. Con: I could not yet find a reliably working debug setup. (not via USB Bridge, not using Linux for building and windows for debugging, not gdb server on Windows etc.pp.) - so windows only is still my main setup.
Sorry mentioning this here again - just to let the world know again - I never had to deal with such a sh* setup from a professional vendor in my whole 30 years of development... Literally I just want to hammer a nail into the wall but all hammers and nails constantly break...

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

Vidar Berg — Tue, 16 Sep 2025 13:22:42 GMT

I have not manage to find a way to consistently reproduce the behavior you describe. I tried to replicate your setup by using the same build target and the lwm sample project. Have you tried to see if you also experience this delay if you call "west flash or west flash --erase" directly from the terminal instead?

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

Vidar Berg — Fri, 12 Sep 2025 13:34:15 GMT

Thank you for the report. This behavior is unfortunate especially with the long build times for this target. I’ve tried to reproduce it here with varying success and have shared it with the developers for their feedback. I’ll will update this ticket once I know more.

RE: VS Code+nrf-connect & west flash mostly rebuilds, and “Erase & Flash” rebuilds again – wasting a ton of time on unchanged builds

cellular_iot — Wed, 10 Sep 2025 07:45:22 GMT

Follow-up observation

It seems this behavior is also triggered whenever I change the selected application config in the nRF Connect for VS Code “Applications” panel.

Even worse: pretty the extension appears to randomly lose focus or re-select another config without me explicitly switching configs. When I click back to my original config and then hit Flash, the extension treats it as if it’s a new build context — which forces the full sysbuild pipeline to run again.

So in practice, I don’t even need to manually switch configs: just the extension losing focus is enough to cause another complete rebuild before flash. That makes the redundant rebuilds even more frequent and disruptive.