Tags: patch grep.el prefers to run "find" and "xargs grep" in a pipeline, which means that "find" can continue searching the filesystem while "xargs grep" searches files. If find and xargs don't support the flags required for this behavior, grep.el will fall back to using the -exec flags to "find", which meant "find" will wait for each "grep" process to complete before continuing to search the filesystem tree. This behavior is controlled by grep-find-use-xargs; `gnu' produces the pipeline and `exec' is the slower fallback. In f3ca7378c1336b3ff98ecb5a99a98c7b2eceece9, the `exec-plus' option was added for grep-find-use-xargs, which improves on `exec' by running one "grep" process to search multiple files, which `gnu' (by using xargs) already did. However, the change erroneously added the `exec-plus' case before the `gnu' case in the autodetection code in grep-compute-defaults, so `exec-plus' would be used even if `gnu' was supported. This change just swaps the two cases, so the faster `gnu' option is once again used in preference to `exec-plus'. In my benchmarking on a large repository, this provides a ~40% speedup. In GNU Emacs 29.2.50 (build 11, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2024-05-15 built on igm-qws-u22796a Repository revision: 734740051bd377d24899d08d00ec8e1bb8e00e00 Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.9 (Green Obsidian) Configured using: 'configure -C --with-x-toolkit=lucid --with-gif=ifavailable'
0001-Prefer-to-run-find-and-grep-in-parallel-in-rgrep.patch
Description: Text Data
--- End Message ---