On Sun, 4 Jul 2004 10:24:18 -0700 (PDT), Ralf W. Grosse-Kunstleve <rwgk@yahoo.com> wrote:
--- Chad Austin <caustin@gmail.com> wrote:
% time libtbx.scons . [snip] 57.200u 6.450s 1:03.74 99.8% 0+0k 0+0io 1394pf+0w % time libtbx.scons --implicit-cache . [snip] 57.600u 6.480s 1:04.21 99.7% 0+0k 0+0io 1394pf+0w
Did you try running with --implicit-cache again? The first time you use it, it caches the dependency information of headers. The second time, it uses that information to speed up the build. In short, you could describe --implicit-cache as adding a test: "if signature of header has not changed, then don't scan it: use the previous headers found." That gets rid of the scanner pass (although MD5 is still run).
It doesn't help here running the no-op build four times in a row:
57.900u 6.360s 1:04.30 99.9% 0+0k 0+0io 1394pf+0w 58.290u 6.760s 1:05.34 99.5% 0+0k 0+0io 1394pf+0w 61.580u 6.570s 1:08.22 99.8% 0+0k 0+0io 1394pf+0w 57.450u 6.760s 1:04.27 99.9% 0+0k 0+0io 1394pf+0w
That's surprising. I'd guess most of the time is spent doing MD5 scans? Have you tried using timestamps?
Nice. Try running with --implicit-cache a few times in a row... then we can compare it with your patch. Of course, with both, you might get an even bigger speedup. :)
Similar observation using the CPPFLAGS trick:
15.340u 1.310s 0:16.82 98.9% 0+0k 0+0io 1402pf+0w 15.220u 1.480s 0:16.81 99.3% 0+0k 0+0io 1402pf+0w 15.280u 1.440s 0:16.78 99.6% 0+0k 0+0io 1402pf+0w 15.160u 1.410s 0:16.65 99.5% 0+0k 0+0io 1402pf+0w
Do I have to run something else before using --implicit-cache? IIRC I also tried --implicit-deps-unchanged and other options at some point in the past. Nothing made a significant difference.
--implicit-cache should work automagically. If it's not working, something else is the bottleneck.
Take a look at Scanner/__init__.py. Should be easy to implement using an environmental variable. :)
OK, I'll put this on my try-again list. :-)
Sounds good. :) Cheers, Chad