FAQ: Speeding up slow build times

Document created by DavidS on Sep 3, 2014
Version 1Show Document
  • View in full screen mode


I’m encountering slow build times with the tools. Is there a way to help speed this up?





There are a few areas that you can look at which will hopefully speed up slow build times. The first area to look at is your machine, does it meet the minimum requirements for our tools? If you’re unsure you can find details of the CCES minimum requirements here. A simple reboot of the machine is recommended as we’ve seen instances where a build that was taking 5 minutes was cut to 21 seconds after a reboot.


Does your application contain large arrays? Large array initialisers can take a long time to parse (this is particularly true for C++, where constructors may need to be called on the constants in the arrays, too). When the compiler encounters large declarations like this, it doesn't emit them to the assembly file as literal initialisers, because that would mean the assembler would also take a long time to parse the initialiser. Instead, the compiler writes the initialiser to a binary file, and then emits a .inc/bin directive to the assembly file. That saves the assembler from repeating the work the compiler's just done.


One workaround for application using large arrays is:

  1. Separate your array definitions into their own .c files, where they are standalone, and extern. Still use the large array initializers as "normal", though.
  2. Compile these .c files to assembly using -S –save-temps. Because of the large initialisers, each file may take quite a while to compile to assembly. In CCES right click on the file and select Properties.
  3. Save the resulting .s and .bin files. There will be one of each, because the compiler will emit the array initialiser into a binary file, to be included by the assembler.
  4. Change your build process, so that you no longer use the .c file for the array definition, and use the assembly file and .bin file instead. This will be much faster.
  5. Keep hold of your .c file, though, so that you can switch back to using the .c file if you need to modify your binary data.


Please be aware, the compiler does have a mechanism for reporting if a compilation is taking a long time, which is the various –progress-rep switches. These are on by default, and will report if the optimiser is taking a long time. However, this mechanism doesn't apply in the case of large data arrays, for two reasons:


  1. With large data arrays, all the time is spent tokenising and parsing the input file. The optimiser comes at the end of the compilation, long after the parsing is complete.
  2. If the compilation is taking a long time because the operating system keeps having to page memory in and out, there will be a significant proportion of the time where the compiler itself is not running, because the operating system cannot spare the CPU cycles. If the compiler isn't running, it cannot report on its own progress to indicate that it is still "thinking".


Other areas to look at for speeding up slow build times include:


  • If you have C++ files in your project you could try using the "-no-implicit-inclusion" switch. (Some customers have seen a significant improvement in compile times when using this switch). By default, when the source contains a #include directive for "file.h" the compiler will also include "file.cpp" to find the template definitions, this switch directs the compiler to not implicitly include the .cpp file.
  • Don't use mounted/networked source/include directories. 
  • Clean out your temporary directory occasionally. A lot of files can slow down the system in general. 
  • Similar to what’s mentioned above, identify files which take a long time to compile and consider breaking them down into smaller files, perhaps on a  per-function basis. If any files are taking an unacceptable length of time to compile, report them to tools support. 
  • Disable pre-processing in generated assembly, if you don't need it (with "-flags-asm -sp"). 
  • Keep files local (so that network traffic isn't required). 
  • Keep PATHs short and local (as above) 
  • Reduce amount of rebuilds needed because of dependencies (i.e. don't have an auto-generated .h file that's included by everything, if you can avoid it)
  • -ipa takes much longer than -O. 
  • Re-configure virus scanner (so that it's not re-scanning all of the tool-chain every time you re-build). 
  • Add more memory. 
  • Export the project to an external makefile and build the project from the command line by invoking the makefile.