Hi Linus, > Date: 2026-11-05 13:48:18-0800 > From: Linus Torvalds > > On Thu, 5 Nov 2026 at 13:24, Alejandro Colomar > wrote: > > > > I think it might indeed be that find(1) is slow at filtering, because > > using git-ls-files(1) is faster without piping to grep(1): > > No. Your find | grep" speedup is because you use two cores for this. > So it's slower, but does it in parallel, which is faster on a machine > with idle cores. > > The reason git ls-files is faster is different: it's because git > ls-files is just that fast. > > And it's so fast that now the pipe overhead is much much more > expensive than git itself, and so doing "git ls-files | grep" is > slower and only adds overhead even if you have idle cores. > > And the reason git ls-files is so fast is because it doesn't do any > directory searches. It just looks at the git index file. > > So git ls-files really does something very different from 'find'. It > just looks at the files that git already knows about, and it basically > only opens '.git/index' and parses it. Oh, thanks! That makes sense. [...] > > Anyway, if you search sources and don't want to care about object > files or other generated files etc, I'd heavily suggest using "git > ls-files" and "git grep" exactly because it's much faster. Indeed, git-ls-files(1) seems more appropriate than find(1), especially after having built a kernel, which makes find(1) go turtle-slow and list the built stuff. > (Ok, "git grep" isn't always faster, the whole regex algorithm issue > can go both ways, but 'git grep' does do the same "just look at files > that are actually known to git" thing, and obviously it can look at > different revisions etc too, so it's really *good* at greapping the > actual committed history, although if you go back in history you'll > obviously be paying a much higher price because now the cost is often > not the regex, but the unpacking of the objects etc) I'm not a fan of git-grep(1), because it's easier to remember grep(1), as I already need to remember it for other stuff. But yeah, a pipe `git ls-files | xargs grep ...` seems what I'd be using. After all, the slow thing is find(1), not grep(1). And I like the separation of concerns, so that one program is listing files, and another one is searching their contents. I'm finding some issues with git-ls-files(1), though: it's listing symlinks, which grep(1) complains about. I wish I could discard those with something like '-type f'. $ time git ls-files | xargs grep ARRAY_SIZE | wc -l grep: scripts/dtc/include-prefixes/arc: Is a directory grep: scripts/dtc/include-prefixes/arm: Is a directory grep: scripts/dtc/include-prefixes/arm64: Is a directory grep: scripts/dtc/include-prefixes/dt-bindings: Is a directory grep: scripts/dtc/include-prefixes/microblaze: Is a directory grep: scripts/dtc/include-prefixes/mips: Is a directory grep: scripts/dtc/include-prefixes/nios2: Is a directory grep: scripts/dtc/include-prefixes/openrisc: Is a directory grep: scripts/dtc/include-prefixes/powerpc: Is a directory grep: scripts/dtc/include-prefixes/riscv: Is a directory grep: scripts/dtc/include-prefixes/sh: Is a directory grep: scripts/dtc/include-prefixes/xtensa: Is a directory grep: tools/testing/selftests/devices/probe/boards/Dell: No such file or directory grep: Inc.,XPS: No such file or directory grep: 13: No such file or directory grep: 9300.yaml: No such file or directory 60570 real 0m0.819s user 0m0.439s sys 0m0.430s $ time git grep ARRAY_SIZE | wc -l 60568 real 0m0.308s user 0m0.443s sys 0m1.172s When searching in old versions, I usually am git-blame(1)ing stuff, so I already know which file to list. In that case, I tend to do `git show v6.0:some/file.c | grep something`. Have a lovely night! Alex > > Linus --