[CMake] Obtaining improved GNU make performance on Makefiles generated by cmake

Bill Hoffman bill.hoffman at kitware.com
Tue Mar 25 16:40:32 EDT 2008


Alan W. Irwin wrote:

> The sum of user+system times is the most relevant number since that will be
> the actual time the user will have to wait if the system is otherwise idle.
> Thus, I have calculated that number above (which also shows the good
> consistency of your repeated measurements).  From those numbers it 
> appears a
> 1-depend target latency is better by ~8.5s, a 60-depend target latency is
> better by ~5.0s, and a full build latency is worse by ~1.2s consistent with
> the idea that the updated Makefile generator produces more efficient 
> results
> for targets with few dependencies, but as the number of dependencies is
> increased, more duplicate work is done by the new method until for full
> builds the results are actually worse than the old (2.4.8) version.  This
> qualitative summary also holds for the PLplot results although the upsides
> of the new method are marginal with an obvious downside for the full build.
> Despite these discrepancies in quantitative results paraview's needs should
> prevail since that project has substantially larger latency than PLplot.
> 
Let's not forget Clinton's 2-cents, that make -j 5 could potentially 
speed things up with the new approach.  This is because in the old 
system it always had to check everything in a single step.  In the new 
way, even though it does duplicate checks, it can do the duplicate 
checks in parallel and have an end result that was faster than 2.4 even 
when building everything.

> Thanks, Bill, for running these paraview latency tests.  My view is they
> should decide the matter unless KDE or some other project with similar or
> larger latency to paraview disagrees with the paraview results you 
> obtained.
> 
No problem.  It is good to make sure we are on the right path, and not 
just making numbers up.

-Bill





More information about the CMake mailing list