|
» 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 ยป |
« Building a better build system - Part 3 Eclipse incremental builder | Main | Debugging DLLs Screencast »
So I've talked about the improvements we made in our build system in earlier articles. These include
1. Allowing the compiler to do the dependency tracking
2. Tracking changes to the mmp (and bld.inf).
3. Allow multiple jobs to be spawned by setting the Make environment variable to "make -j N" to allow the make rules to run concurrently in multiiple jobs and thus the compilation time will be faster.
4. Allow the user to turn on the Eclipse incremental builder to determine if anything has changed in the workspace.
But how much faster? We did some example benchmarking to give us an idea.
Our first round of benchmarking was done with a Nokia S60 3.1 kit using a fairly large project called telephony. We tested on single, duo and quad core machines for the emulator and on-device using RVCT 2.2 compiler. Let's look at the results:


By design the dependency tracking times can be greater than the command line on initial builds because the compiler is doing the dependency tracking This can be seen on line 1-3.. But on subsequent builds is where the real benefits are seen as the dependency tracking times are decreased substantially from command line. This can be seen on lines 4-5. Build times are decreased even further when concurrency is turned on. This can be seen on line 6.
When the Eclipse incremental builder is turned then a rebuild takes no time. This can be seen in lines 7-8.
So looking strictly at the numbers the improvements to the build system were an enormous success! Of course due to complexity of some projects(such as projects using circular dependencies) the build system may not always work but we've rarely had reports of this. But that is why we give you the option to switch over to the regular command line system.
It also seems to help when you increase the memory and number of cores. So you may want to think about taking the boss out to dinner and asking for an upgrade in-between martini's!