| Modern applications can often consist of many thousands of source files which can take a considerable amount of time to compile and link. This FAQ considers various ways of decreasing the time your code takes to build. What happens when the compiler is invoked? When you invoke the compiler, effectively three steps are carried out: - The compiler is actually loaded and begins to execute.
This will normally take a fixed period of time.
- The compiler tries to obtain a license.
Assuming a license is available this should take a similar period of time for each request, though if a floating license is being used this will depend upon network traffic, and whether a license is free on the server. Note that whereas an ADS 1.2 build will fail if no license is available, the RVDS compilation tools will in most circumstances wait for a license to become available.It should also be noted that the process of obtaining a floating license is also much more involved than obtaining a node locked license. With node locked, the compiler simply has to locally parse the file to check that there is a valid license. With floating, the compiler has to check where the license is, send a message through the TCP/IP stacks over the network to the server, then wait for a response. When this is received it then needs to check whether it has been granted a license. Then after the compile has completed the license has to be returned back to the server. Thus floating licenses provide the flexibility of anyone connected to the local network being able to use the tools, but at the cost of speed. If speed is your priority, then you should consider obtaining some node locked licenses for your build machines, or perhaps some node locked licenses locked to USB network cards so that the licenses can be moved between machines as required.
For more information on floating licences you should read our License Management FAQ entry: Optimising license checkouts from a floating license server.
- The compiler actually compiles your code.
The time taken for this step is dependant upon the complexity and size of the file being compiled. It is worth noting though that compiling a small number of larger files may be quicker than compiling a larger number of smaller files. This is because the longer compiler time per file may be offset by the smaller amount of time spent loading/unloading the compiler and obtaining licenses.Taking this one stage further, it is actually possible to have a single invocation of armcc (and single license checkout) to compile many files. To do this rather than having a build script that looked like armcc file1.c ....
armcc file2.c ....
armcc file3.c ....
:
:
you could instead change this to armcc file1.c file2.c file3.c ..... You could list all your .c files in a single "via" file, invoked with: armcc -via sources.txt This mechanism dramatically reduces license checkouts and compiler load/unloads and can give huge improvements in performance. It does have some limitations though:
- Same options to all files.
- Difficult to convert to from existing build systems.
- Usability depends on source file structure and dependencies.
- Poor "debug illusion" for IDEs (which file had compile errors?).
Note: The RVCT compiler will not compile subsequent files in the list, if it finds an error in one of the files, whereas the older ADS compiler will attempt to compile all subsequent files regardless of any error(s).
The effect of include paths... Include paths can also increase build times. You should try to keep the number of include paths passed to the compiler to the minimum possible. If you have a lot of include paths, make sure the files you need to include the most often exist in directories near the start of the include search path - not near the end! You should also try to avoid including things more than once. This again can slow things down. You can also guard against including headers multiple times. For instance, if you have a header file 'foo.h', then add: #ifndef foo_h
#define foo_h
:
// rest of header file as before
:
#endif /* foo_h */
You should also use the compiler option -W+g to warn about unguarded header files. Use of parallel make... If you are using a makefile based build environment you could consider the use of a parallel make (functionality provided by some make tools, such as gnu make). Even on a single machine with a single processor, this could well give you a performance boost by effectively carrying our 2 (or more) compiles in parallel. Typically to do this you need to use "make -j N", where N is the number of compile processes you want to have running in parallel. The reason this can give you a boost is that it can allow you to "hide" - the network delay caused by a floating license, - general I/O access (eg loading/saving files to disk) by fully using the CPU during these times with another compile process. If you have multiple processor machines then you can make use of even more parallelism by using "make -j N*M" (where M is the number of processors). There is an interesting discussion on this subject at: http://developers.sun.com/solaris/articles/parallel_make.html Windows Vs Unix... Linux and Solaris generally give better build speed than Windows. Note that although ADS 1.2 is only strictly supported on a fairly old version of Redhat, this is largely due to issues at the GUI level. Therefore it is possible that the command line build tools may function correctly on more recent versions but this is not guaranteed. For more details on what platforms support ADS and RVDS see the FAQ: On what platforms will my ARM tools work? If you are using Windows though, there are things that can be done to "tune" the performance of Windows (at a general level) and such things may help to increase the percentage of CPU time you see being used for your build. At a simple level, turning off virus checking software can help, but a google for "tune windows performance" turns up a lot of information available on tuning Windows at the OS and the hardware level.
Related:
| 
Back to FAQs index
