|ARM Technical Support Knowledge Articles|
What happens when the compiler is invoked?
When you invoke the compiler, three steps are carried out:
The process of obtaining a floating license is more involved than obtaining a node-locked license. With a node-locked license, the compiler simply has to parse the file to check that there is a valid license.
With a floating license, 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.
Floating licenses provides flexibility, but at the cost of speed. If speed is your priority, then you should consider obtaining node-locked licenses for your build machines, or some node-locked licenses locked to USB network cards which can be moved between machines as required.
Setting the environment variable
1, on client and server machines, improves FlexNet license server system performance when processing license requests. However, this must be used with caution, as it may cause an increase in network traffic.
For more information on floating licenses please see the License Management FAQ entry: Optimizing license checkouts from a floating license server.
Taking this one stage further, it is possible to have a single invocation of armcc (and single license checkout) to compile many files. To do this, instead of having a build script like:armcc file1.c ....
you could instead use:armcc file1.c file2.c file3.c .....
Alternatively, 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:
-O3enables multifile compilation, which may increase build times. If you wish to disable multifile compilation use the
The effect of include paths
Include paths can also increase build times. You should try to keep the number of include paths to a minimum. 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.
You should also try to avoid including headers more than once, which can increase compile times. You can guard against including headers multiple times. For example, if you have a header file 'foo.h', then add:#ifndef foo_h
You can 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 using parallel make (functionality provided by some make tools, such as gnu make). To do this you typically use "make -j N", where N is the number of compile processes you want to have running in parallel. Even on a single machine with a single processor, this can give you a performance boost by allowing you to hide network delays and general I/O accesses (for example, 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).
Operating System Choice
Linux generally gives better build speed than Windows.
If you are using Windows, there are ways to "tune" the performance of the OS (at a general level) which may help to increase the percentage of CPU time being used for your build. At a simple level, turning off virus checking software can help, but an internet search for "tune windows performance" provides a lot of information.
In general, ARM development tools will work on Windows and Linux platforms that were in common use at the time of development. Testing will have been carried out on all of the supported platforms for that product. For more information, please refer to the documentation and/or release notes for the version of tools you are using.
Article last edited on: 2016-06-01 20:22:11
Did you find this article helpful? Yes No
How can we improve this article?