summaryrefslogtreecommitdiffstats
path: root/.gitattributes
diff options
context:
space:
mode:
authorTavian Barnes <tavianator@tavianator.com>2021-11-17 14:33:01 -0500
committerTavian Barnes <tavianator@tavianator.com>2021-11-17 14:49:04 -0500
commitac1d28ea6bf9c0bd7b41725095a5b41ac8a08121 (patch)
treefc546039470ce0c9f7daa2188be6bee915c7c6c1 /.gitattributes
parent9b50adaaaa4fedc8bda6fcf32595ecf7a682fa8b (diff)
downloadbfs-ac1d28ea6bf9c0bd7b41725095a5b41ac8a08121.tar.xz
exec: Find ARG_MAX with binary search after E2BIG
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
Diffstat (limited to '.gitattributes')
0 files changed, 0 insertions, 0 deletions