Why is NCS build so slow?

I switched from segger ses to NCS for the nrf54l15. I am really surprised, that the build process takes several times longer now.

Especially, when the proj.conf has to be edited and often settings have to be tried out as the documentation can be really really thin it takes several minutes until the programm can be flashed.

I observed, that the TF-M gets build every time, even nothing concerning the TF-M has changed. Isn't possible to cache unchanged parts?

Parents
  • Hi Florian, 

    I switched from segger ses to NCS for the nrf54l15. I am really surprised, that the build process takes several times longer now.

    Unfortunately , it's the side effect of moving away from the bare metal architecture and switch to having an RTOS built-in. So there are a lot more to do for the compiler and the linker to build a project. Our softdevice is also integrated into Zephyr and only the controller is separated as a precompiled binary. 
    So it takes longer to build an nRF Connect SDK application. 

    Everytime you edit prj.conf the project configuration will be re-generated and all the files need to be re-built. It's similar to when you modify sdk_config.h in the nRF5 SDK. 

    I understand the frustration with long building time, but it's how it is. The benefit is now we can handle much more complex application much easier, and it's now very straight forward to switch between different chip/families, much easier than with nRF5SDK. 

    One thing we noticed is that it's much faster to build on Linux compare to Windows. I guess due to some optimization with the compiler. In addition Windows' antivirus software is also causing the build to be slower. We noticed that if we put the nRF Connect folder into exclusion folder of Windows Security setting, the build can be done much faster. 


    It's just our observation, it's your decision to choose to put the folder into exclusions list or not. 

    You can also shorten the time of build by not building with -ns variant for development and switch to -ns after you are done with basic development. This can save the time to build TF-M. Same applied for building with MCUBoot. 

Reply
  • Hi Florian, 

    I switched from segger ses to NCS for the nrf54l15. I am really surprised, that the build process takes several times longer now.

    Unfortunately , it's the side effect of moving away from the bare metal architecture and switch to having an RTOS built-in. So there are a lot more to do for the compiler and the linker to build a project. Our softdevice is also integrated into Zephyr and only the controller is separated as a precompiled binary. 
    So it takes longer to build an nRF Connect SDK application. 

    Everytime you edit prj.conf the project configuration will be re-generated and all the files need to be re-built. It's similar to when you modify sdk_config.h in the nRF5 SDK. 

    I understand the frustration with long building time, but it's how it is. The benefit is now we can handle much more complex application much easier, and it's now very straight forward to switch between different chip/families, much easier than with nRF5SDK. 

    One thing we noticed is that it's much faster to build on Linux compare to Windows. I guess due to some optimization with the compiler. In addition Windows' antivirus software is also causing the build to be slower. We noticed that if we put the nRF Connect folder into exclusion folder of Windows Security setting, the build can be done much faster. 


    It's just our observation, it's your decision to choose to put the folder into exclusions list or not. 

    You can also shorten the time of build by not building with -ns variant for development and switch to -ns after you are done with basic development. This can save the time to build TF-M. Same applied for building with MCUBoot. 

Children
No Data
Related