[C++-sig] Python, Boost.Python, and SCons

[Chad Austin]

On Sun, 4 Jul 2004 10:24:18 -0700 (PDT), Ralf W. Grosse-Kunstleve
<rwgk at yahoo.com> wrote:
> --- Chad Austin <caustin at 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