Speed up your CCES compiles on Windows by a factor of 5 or 10

ADI distributes a version of make.exe that was built FIFTEEN YEARS AGO.  Parallel builds do not work because this version of make.exe doesn't properly honor the parallel build flags.  You can hack around this using makefile.defs, but the build output is all scrambled, making it difficult to figure out exactly what the errors are in your compile, because this version of make.exe doesn't have the feature to keep the output in sync.

Do yourself a big favor and go find a modern version of GNU make.exe. The only place I could find it was in the Chocolatey distribution.


After installing Chocolatey and typing “choco install make”, I pulled make.exe out of C:\ProgramData\chocolatey\lib\make\tools\install\bin and copied over the make.exe in the root of the CCES folder.  I then went into each of my projects in the “C/C++ Build” section and set “Enable parallel build” on the Behavior tab.  I then added the “-O” flag (output sync) to the Build command on the Builder settings page.  Wow oh wow!  My ARM project (with FreeRTOS) builds in 9 seconds, my Sharc projects build in 17 seconds.  And the “-O” flag insures the output log isn’t all messed up.  It is great, give it a try!

  • Hi dsmtoday,

    thank you for your suggestion. We're also sometimes facing very long build times. I am building on a Windows machine for the ADSP-BF70x target (Blackfin DSP family).

    I've run several builds and measured the execution time (minutes:seconds) for the different versions of make using the build command "make -j8":

    make.exe shipping with CCES 2.10.0 ("GNU Make 3.811", "Copyright (C) 2006", "Windows32"):

    - 01:24
    - 01:33
    - 02:34
    - 02:23

    make.exe installed with chocoportable ("GNU Make 4.3", "Built for Windows32", "Copyright (C) 1988-2020"):

    - 01:42
    - 01:55
    - 02:16
    - 02:10

    I could not observer any significant speed-up in build time. However, some other factors may play a role: the build tool (compiler/linker) called by make, the anti-virus system running on my machine, generic system performance of my workstation (CPU type + RAM).

    In addition, I run some pre- and post-build steps that should have constant run time (estimated time is ~15 seconds) - but they should not be the major part of my build.

    But you are right, using the -O / --output-sync switch really may help keeping a clean build log (but I expect speed loss due to required sync of outputs).

    I am happy about additional hints and thoughts.


  • Glad you tried it out, but it seems that you already had parallel builds working before (either using commandline, or overriding the default commandline in the GUI).  The point of the new version of make.exe is that parallel builds will work using the simple GUI flag to turn the parallel builds on, you don't have to run from the command line or modify the default make command or make files to make parallel builds work.  That was one of the problems I was seeking to fix because we always just build from the GUI here.

    When I got parallel builds working properly from the GUI, my compile times went from several minutes to several seconds (12 core processor, SSD, plenty of RAM).  It especially sped up the Sharc compilation because ADI's compiler for the Sharc is many times slower than the gcc that is built for the ARM.

    I'm hoping to help others who are working from the GUI and may not know that parallel builds are possible, or have turned the parallel flag on in the GUI, but still can't build in parallel because the default make.exe does not honor the parallel flag properly.  I also wrote this as a reminder to ADI to please update the make.exe that they ship with the product.

  • 0
    •  Analog Employees 
    on Aug 12, 2021 8:22 AM in reply to dsmtoday

    Hi Todd,

    We are already tracking this upgrade request internally.

    Also, We have planned to upgrade to latest GNU Make in upcoming release of CCES version 2.10.1


  • Hi Santha,

    It would be super great if you could also look into what is going on before the build starts.

    I just clocked the time from pressing the build button until the build started and it was 18 seconds.

    So the build below, which does nothing, takes 18 + 7 = 25 seconds.

    If there is anything to be done to cut this time please let me know.

    08:42:45 **** Incremental Build of configuration Debug for project xxxx ****
    make -j12 all
    make: Nothing to be done for `all'.

    08:42:52 Build Finished. 0 errors, 0 warnings. (took 6s.922ms)

  • 0
    •  Analog Employees 
    on Aug 23, 2021 2:55 PM in reply to dehkl


    We are unable to simulate this behavior here in simple CCES project.

    Could please you try enabling the "Building projects configurations" option in the IDE by following the below steps.

    1) Click on the Window->Preferences menu to bring up the Preferences dialog
    2) Click on C/C++->Indexer and select "Build" from the drop down list.
    3) Then enable the option "Build configurations only when there are Eclipse resource changes within the project and its references" in the "Building projects configurations".Refer the attached screenshot(build_config.jpg).
    4) Click on Apply and close the Preferences dialog box.

    When above option is enabled, builds configurations only when there are resource changes within the project and its references.

    Also, we recommended to make sure whether "Incremental build" option is enabled in your CCES. When this option is enabled, only affected or modified files gets rebuild during compiling.

    You can find "incremental build" option in below two locations.Please ensure that, it is enabled in both and column beside that is set to "all".

    Right click on project > Properties > C/C++ Build > Behaviour tab > Build(incremental build). Refer the attached screenshot Properties.jpg

    Window > Preferences > C/C++ > New C/C++ project wizard > Makefile Project > Behaviour tab > Build(incremental build). Refer the attached screenshot Preference.jpg

    Typically when we see slowness it is caused by the antivirus, or USB contention, etc. Can you please open the Windows Task Manager and monitor CPU performance when performing these debug operations; is there a significant spike in CPU usage.

    Also, can you please try importing the project in the new workspace and try build your project.

    Please refer the below linked FAQ's, which might be helpful to you.
    FAQ: Speeding up slow build times

    FAQ: CCES builds applications much slower after installing non-ADI software on my machine

    If you are still facing the issue can you please try to uninstall and reinstall the CCES. Before uninstalling take a backup of the license.dat file.
    License.dat file is located at C:\ProgramData\Analog Devices\CrossCore Embedded Studio

    Please let us know whether which version of CCES you are using and whether you are facing the issue with all the project or with the specific project. Also try with the different PCs and let us know how you gets on.

    If you are facing the issue with the specific project, please share us the project. This will help us to assist you further.

    Best Regards,