|
» Subscribe » Favorite Links » What is S60? » Freeware & Trials » S60 devices » Hints and tips » About this blog |
» Blognotes (15) » Bugs and Workarounds (4) » Build tools (5) » Carbide.c++ 1.1 (4) » Carbide.c++ 1.2 (8) » Carbide.c++ 1.3.x (9) » Carbide.c++ 2.0.x (12) » Carbide Plug-Ins (4) » CodeWarrior (2) » FAQ (6) » Future directions (25) » General (48) » Off-topic (5) » On-device debugging (13) » Performance Investigator (2) » Product features (18) » Product releases (16) » Screencast (14) » Support (36) » Tool setup (6) » UI Designer (8) » Usability (18) » Work in Progress (14) » Write-build-debug (4) |
|
» New Remote Connections View » Terminating Multiple Processes » Agile Tuning of the Austin Team » Introduction to the workspace screencast » Adding DLLs while Debugging |
|
Subscribe to RSS feed For email notification, please click here ยป |
« Do you have the right TRK Version? | Main | Improving the N-gage development experience »
Another build issue we addressed in Carbide 1.3 was a performance issue concerning compile times when compared to CodeWarrior. CodeWarrior has an option to run compiles concurrently, which reduced overall build time signficantly. Make has a similar feature which can be enabled with the -j switch. When specified it will run the make rules concurrently in multiple jobs and thus the compilation time will be faster. This works on multi-core and hyper-threaded machines.
Make will spawn N non-dependent rules at once, where N is the number specified after the -j switch. For example, if -j 4 was specified, there could be as many as 4 instances of the compiler at any given time, each compiling a different source.
Carbide doesn't call make directly, only "abld" so we needed some way to get the switch passed. So we simply set the Make environment variable to "make -j N", where N is the number of jobs to be spawned. There are seperate make calls for the different "abld build" steps. As mentioned in the previous article thos steps are 'abld export', 'abld makefile', 'abld library', 'abld resource', 'abld target' and 'abld final' respectively.
In practice we found this didn't always work well. When building resource files in parallel we found that there could be dependency problems that would cause the build to fail. We found a similar issue with the 'abld library' stage. We assumed that there wouldn't be a significant performance hit if we didn't use the -j switch for those two stages, so for 'abld resource' and 'abld library' we don't specify it.