#
cca88a81 |
|
28-Aug-2019 |
Augustin Cavalier <waddlesplash@gmail.com> |
tools/exec: Implement basic environment overrides. VAL=xxx... and VAL=$VAL:xxx... are supported; all other syntaxes will fail with an error message. When combined with a build/jam patch that will come in a later commit, this makes it possible to build a large number of targets using exec as JAMSHELL; including all of libroot. The performance difference is extremely obvious: jam -j2 libroot, JAMSHELL=/bin/sh (32-bit Haiku) real 1m43.571s user 1m10.961s sys 1m7.965s jam -j2 libroot, JAMSHELL=exec real 1m28.364s user 0m58.190s sys 0m57.563s So that is a savings of 15.21 seconds, or 15% of the build time. Something that is less I/O bound and more fork-bound (e.g. linking application catalogs) will almost certainly see an even bigger performance difference. Changes to add the necessary JAMSHELL overrides for those targets which need it, in order to make it possible to enable usage of "exec" by default, will be coming over the next few days/weeks...
|
#
a5f58aba |
|
28-Aug-2019 |
Augustin Cavalier <waddlesplash@gmail.com> |
tools: Add an "exec" tool. This utility takes command-strings, e.g. "gcc -c file.c -D...", parses them into an argv, and then execvp()s that. The use-case is Jam, which cannot do this itself, but instead simply calls JAMSHELL (usually just "/bin/sh -c") to do that for it. Shells in general have a large amount of overhead (and bash in particular is especially bad here), so using a utility like this as JAMSHELL in most cases can be a significant speed-up. For example, on Haiku (32-bit): $ time sh -c 'for i in {1..100}; do sh -c "./exec test"; done' real 0m3.335s user 0m1.603s sys 0m1.612s $ time sh -c 'for i in {1..100}; do ./exec test; done' real 0m1.547s user 0m0.597s sys 0m0.867s So this means for every 100 executions, using bash has about 3.3s of overhead, and this tool cuts out over half of that. Probably for longer command strings, the overhead is significantly greater. But that should be clear soon enough...
|