Most linux machines can likely handle a few concurrent indexing jobs
for the shared objects in one binary. This modification uses SIGUSR1 and
subshells to simulate a semaphore with task queue that significantly
increases the speed of execution over a newly built set of binaries.
By default, this script executes 4 parallel indexing tasks, though the
concurrency be controlled by setting the INDEX_TASKS shell variable.
Here are bencharks from my z620, using a component build browser_test
binary as the target:
6 threads browser_threads:
real 0m36.307s
user 0m51.680s
sys 0m13.150s
4 threads browser_threads:
real 0m39.243s
user 0m53.010s
sys 0m12.230s
1 thread browser_threads:
real 1m12.099s
user 0m53.300s
sys 0m13.580s
This was on an SSD. Benefit hit diminishing return after 4 threads and
may actually taper off sooner.
BUG=none
R=piman@chromium.org
Review URL: https://codereview.chromium.org/23130007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@217815 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Without this, gdb-add-index incorrectly skips DSO dependencies if running from a symlink. $(pwd) returns the path to your directory via the symlink, but ldd returns the "realpath". Using dirname allows you to match a substring of the path returned by ldd.
BUG=none
Review URL: https://chromiumcodereview.appspot.com/10913264
git-svn-id: http://src.chromium.org/svn/trunk/src/build@156968 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
For linux users who are going to debug chromium, running gdb-add-index
on the binary first will significantly speed up debugger start time.
The originating RPM is gdb-7.4.50.20120603-1.1.x86_64.rpm. The script is
just a bash script version of the instructions in the gdb man page.
BUG=none
TEST=ran it on a statically linked browser_tests locally. verfied .gdb_index section exists
and that gdb does startup faster (from ~20 secs to ~3 seconds)
Review URL: https://chromiumcodereview.appspot.com/10695024
git-svn-id: http://src.chromium.org/svn/trunk/src/build@144644 4ff67af0-8c30-449e-8e8b-ad334ec8d88c