Re: [PATCH v1 1/2] string: Add strprefix(), and deprecate str_has_prefix()

[Alejandro Colomar]

Hi Linus,

> Date: 2026-11-05 13:48:18-0800
> From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
>
> On Thu, 5 Nov 2026 at 13:24, Alejandro Colomar
> <alx+linux-hardening@xxxxxxxxxx> 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

-- 
<https://www.alejandro-colomar.es>

Attachment: signature.asc
Description: PGP signature