Hi Bill: I just now tested (with the build on one of the PLplot C examples) the assertion that specific targets will have less latency with the new approach. Here are the results.
[EMAIL PROTECTED]> make x10c [ 0%] Built target plhershey-unicode-gen [ 0%] Built target plhershey-unicode.h_built [ 0%] Built target csirocsa [ 16%] Built target csironn [100%] Built target plplotd [100%] Built target x10c As you can see from this, the number of dependencies is fairly small. Furthermore, the VERBOSE=1 results indicate there are no actual commands being run by the above so this is a measure of true latency. Here are the corresponding latency results: 2.4.8: [EMAIL PROTECTED]> time make x10c >& /dev/null real 0m0.217s user 0m0.160s sys 0m0.068s 2.7-20080324: [EMAIL PROTECTED]> time make x10c >& /dev/null real 0m0.209s user 0m0.168s sys 0m0.036s Repeat runs indicate for this special case with a small number of dependencies, the timing errors are typically +/- 0.002 s. The conclusion therefore is the cvs version wins on latency for a specific target by a marginal amount that is just above the timing noise. On 2008-03-24 15:28-0400 Bill Hoffman wrote:
OK, so for a small project like PLplot, where it does a make in 1 to 2 seconds if nothing needs to be done, this stuff really does does not matter that much. As for the new way cmake does the depend stuff, I think the new approach is much better for larger projects like KDE/ParaView.
Large projects have the most serious potential latency problems (could be minutes rather than seconds if the number of dependencies is very high) so I agree they should be the ones driving latency improvements rather than PLplot. The only advantage of using PLplot for such tests is the initial build can be done in less than a minute so doing differential comparisons between various CMake versions is easy to do. In any case, it's fundamentally important not to guess about latency because reducing latency is generally a hard problem. Thus, before the next release I hope somebody steps forward with actual latency numbers for specific targets and the "all" target for large projects like KDE/ParaView. But it currently doesn't look good since the indications from the PLplot tests (which so far is the only hard data that has been reported) is the latency for "make all" will be substantially worse while the latency for specific targets with a lot fewer dependencies then "all" are only marginally better for the cvs version compared to 2.4.8. The principal conclusion I want to emphasize is the PLplot latency results are just an indication of what to expect in general, and what we need is hard latency numbers for big projects like KDE, ParaView, etc., (where latency issues should be more severe than in the PLplot case). That's the only way we can move forward with any further attempts to substantially improve latency. I have previously asked Alex to do the KDE case. Bill, would you be willing to measure latency for ParaView for cmake 2.4.8 and the present cvs version of CMake? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake