| Age | Commit message (Collapse) | Author |
|---|
|
Previously we would shrink the command by one argument at a time until a
successful execution. This is okay if the ARG_MAX estimate is just a
little bit off, but is terribly slow when it's off by a lot.
One situation where it's very far off is when a 32-bit build of bfs
launches a 64-bit binary. In this case, bfs thinks the argv pointers
are 4 bytes, while they actually take up 8 bytes. The performance is
quite bad:
$ time ./bfs-64 ~/code/linux -exec echo {} + >/dev/null
./bfs-64 ~/code/linux -exec echo {} + > /dev/null 0.03s user 0.07s system 99% cpu 0.095 total
$ time ./bfs-32 ~/code/linux -exec echo {} + >/dev/null
./bfs-32 ~/code/linux -exec echo {} + > /dev/null 0.08s user 10.33s system 100% cpu 10.390 total
After this change, performance is much better:
$ time ./bfs-32 ~/code/linux -exec echo {} + >/dev/null
./bfs-32 ~/code/linux -exec echo {} + > /dev/null 0.03s user 0.08s system 99% cpu 0.110 total
|
|
|
|
The API remains similar, with some added accessor functions for lazy
initialization of the pwcache and mtab.
|
|
|
|
|
|
POSIX explicitly forbids this extension:
> Only a <plus-sign> that immediately follows an argument containing
> only the two characters "{}" shall punctuate the end of the primary
> expression. Other uses of the <plus-sign> shall not be treated as
> special.
|
|
|
|
|
|
Thanks to https://www.in-ulm.de/~mascheck/various/argmax/
|
|
|
