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
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
