Need help debugging slow scons runtime

问题

I am working on two projects using scons to build. One works great, while the other (more complicated) project is very frustrating. Here is what I see when running scons for the second project:

S time scons
scons: Reading SConscript files ...
<<< Generates some code, output seen in console >>>
scons: done reading SConscript files.
scons: Building targets ...
<<< 30+ second delay, with no output >>>
<<< Building occurs, with output, only 2-3 seconds >>>
scons: done building targets.
<<< 15-20 second delay, no output to console >>>

real  0m54.600s
user  0m2.612s
sys   0m9.236s
$

So it seems to read the SConscript files quickly enough, but when it is done, there is a huge 30+ second delay where it seems to be doing nothing at all. If I hit Ctrl-C here, the delay is still there; it won't process the Ctrl-C and terminate the run until the delay elapses. Similarly, there is another mystery delay after it is done with everything; this delay also is not interruptable.

I do not know what is going on, but it is frustrating to wait 54 seconds for what should be about 4 seconds! I haven't been able to find a way to have scons tell me what it is doing during those delays. Does anyone know how to get more information on what it is doing?

Update: I ran scons with the profile= option to get profiling information, then printed out a sorted list; here are the first several items:

Sun Mar 13 17:46:04 2016 scons.profile.data

     1253379 function calls (1208007 primitive calls) in 61.303 seconds

Ordered by: internal time, function name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
       41   32.778    0.799   32.783    0.800 {cPickle.loads}
        1   17.691   17.691   17.691   17.691 {cPickle.dump}
      456    5.337    0.012    5.337    0.012 {method 'read' of 'file' objects}
       24    2.844    0.118    2.844    0.118 {posix.waitpid}
        5    0.245    0.049    0.245    0.049 {built-in method poll}
   . . .
      230    0.016    0.000    0.029    0.000 {cPickle.dumps}

The remaining 1000+ entries are all less than 0.1 seconds tottime. Note that the first two entries match the two mystery delays! (For completeness, I also show the one other cPickle call, even though it is very small.) What could be causing cPickle to use so much time?

Update 2: I ran it again today, and got the following timing:

real  1m42.446s
user  0m4.104s
sys   0m11.648s

Note that this was just compiling two small .c files! Then, I renamed the .sconsign.dblite and ran it again; of course, it rebuilt everything, but was already much faster:

real  0m34.229s
user  0m28.392s
sys   0m2.932s

Much better! So now, I ran it again with the same two files needing compilation, and I get this:

real  0m3.494s
user  0m2.556s
sys   0m0.460s

Now, that is good! I decided to look at the .sconsign.dblite and the old version, and found the following:

$ ls -la .scons*
-rw-rw-r-- 1 rsg rsg     189513 Mar 14 20:31 .sconsign.dblite
-rw-rw-r-- 1 rsg rsg 1440507770 Mar 14 20:23 .sconsign.dblite.save

A factor of 7600 difference!!! So for now, it seems this is resolved, though it would be nice to know what happened to the .sconsign.dblite, and how to prevent it from happening again.

Environment:

$ scons --version
SCons by Steven Knight et al.:
    script: v2.1.0.r5357[MODIFIED], 2011/09/09 21:31:03, by bdeegan on ubuntu
    engine: v2.1.0.r5357[MODIFIED], 2011/09/09 21:31:03, by bdeegan on ubuntu
    engine path: ['/usr/lib/scons/SCons']
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 The SCons Foundation
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04.5 LTS
Release:        12.04
Codename:       precise
$ python --version
Python 2.7.3

Also, Ubuntu is running in a VM, under VirtualBox v5.0.16 on a decent Windows 7 machine.

回答1:

Due to the huge amount of time spent unpickling, it's possible the .sconsign file is either corrupted or for some reason exploded with too much data, it may be wise to rename it and see if that resolves your issue.

mv .sconsign.dblite .sconsign.dblist.save

If it does, you can inspect the contents of the old file with

sconsign .sconsign.dblite.save

This occasionally (pretty rarely actually) happens and we've not yet been able to reproduce it for developers and fix it.

来源：https://stackoverflow.com/questions/35973789/need-help-debugging-slow-scons-runtime

标签

scons