Improving Pristine Build Times via Precompiled Hex Files

[Nolan_G]

Hello,

I've been investigating improving pristine build times in VSCode for my nRF5340, and I saw some Kconfig options for "build strategies" for B0 and mcuboot to "use hex file instead of building". I'm referring to B0_BUILD_STRATEGY_USE_HEX_FILE and MCUBOOT_BUILD_STRATEGY_USE_HEX_FILE.

Do these options imply that we can build our NSIB and MCUboot images one time and use their hex files for the next pristine builds, or am I mistaken in my understanding of these options? I would like to find a method to only pristine build the images that change to speed up the time it takes.

Also, is it possible to not have VSCode pristine build my project when I restart VSCode? As it stands, my pristine build takes about 3 minutes and 30 seconds, but for my nRF52840 that I used before switching to the nRF5340, a clean build took a matter of a few seconds. Why is this, and what changed?

Also, are there any other major tips for improving build times? I'm on Windows. I heard WSL was a good option, so I'll be researching that extension for VSCode next.

Thanks for your help in advance!

[Raoul]

Hi Nolan,

Do these options imply that we can build our NSIB and MCUboot images one time and use their hex files for the next pristine builds, or am I mistaken in my understanding of these options? I would like to find a method to only pristine build the images that change to speed up the time it takes.

Yes, my understanding is that that's exactly what they do.

You could see this case for info on how to use them:  RE: How to use a prebuilt (MCUBOOT)HEX file of the child image and include it with the parent image? 

Also, is it possible to not have VSCode pristine build my project when I restart VSCode?

I'm surprised I never realised this before, but you are right, it happens for me as well. I can't think of any good reason for this, so I'll ask the VS Code team to clarify why restarting VS Code would force a pristine build.

As it stands, my pristine build takes about 3 minutes and 30 seconds, but for my nRF52840 that I used before switching to the nRF5340, a clean build took a matter of a few seconds. Why is this, and what changed?

I'm sorry, could you clarify what you mean here? Are you saying that a pristine build for the same project on nRF5340 takes minutes longer than a pristine build on the nRF52840? If so, that sounds very strange.

Some months ago, I started getting curious about build times as well. From what I've been seeing with some of my colleagues, you are definitely right in saying that WSL offers a speedup. It seems builds are just faster on Linux systems in general - including WSL, despite the virtualization.

Note that you would have to install a new toolchain within the the Linux subsystem, so it's a bit more involved than simply installing an extension.

I believe that one of the main culprits on Windows is Windows Defender. I think significant speedups are achievable by whitelisting parts of the SDK or the build folder, but I haven't figured out (meaning I haven't measured to make comparisons) the exact details of what to whitelist yet. I think it's worth trying to whitelist /ncs/ (wherever you installed it) in its entirety, and also your build folder if you are building "freestanding" applications.

If I come across anything useful on the topic , I'll try to update this case.

Best regards,

Raoul

[Nolan_G]

Hi Raoul, thanks for the reply!

Raoul said:

You could see this case for info on how to use them:  RE: How to use a prebuilt (MCUBOOT)HEX file of the child image and include it with the parent image?

I'll definitely check this out and see what this recommends doing.

Raoul said:

I'm sorry, could you clarify what you mean here?

For this, I meant for developing with the nRF52840 using SEGGER. I should've clarified that I was talking about SEGGER rather than VSCode. My mistake.

Raoul said:

I think significant speedups are achievable by whitelisting parts of the SDK or the build folder

I'll give this a shot. Thanks!

I look forward to any updates.

Regards,

Nolan

[Raoul]

Hi Nolan,

My pleasure.

Nolan_G said:

For this, I meant for developing with the nRF52840 using SEGGER.

That's still surprisingly short! I wonder if Segger Embedded Studio is doing a full pristine build in that case, or caches.

By the way, if you see any benefit from whitelisting anything in particular (if that's the path you pursue), please let us know. There are colleagues interested in speeding up their builds as well...

Best regards,

Raoul

[Nolan_G]

Hi Raoul, I recently switched to using WSL and have seen improvements from 3min 30sec to 1min 5sec pristine build times. Disabling Windows Defender improved the build time from 3min 30sec to 3min, but that was nothing compared to WSL. With Windows Defender disabled AND using WSL, the build time was around 55 seconds, but disabling Windows Defender is kind of a pain, so it wasn't worth the 10 seconds it would save.

I've not tried using prebuilt subimage hex files yet, as we keep making changes to our bootloader conf files, but once we're done changing them, I'll give the prebuilt images a try.

Thanks, and I'll let you know if I test anything else.

[Raoul]

Hey Nolan, thanks for reporting!

I hadn't seen the numbers before, the difference is quite stark. You've convinced me, I should just set up NCS in WSL some day soon.

I think it will be hard to beat those times in Windows, so just stick to WSL if that works for you. Still, if I hear of a good tip for improving build times in Windows, I'll let you know.

Best regards,

Raoul