Hi Andy,

> Date: 2026-11-05 20:12:37+0200
> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> On Thu, Nov 05, 2026 at 08:08:57PM +0200, Andy Shevchenko wrote:
> > On Thu, Nov 05, 2026 at 06:46:18PM +0100, Alejandro Colomar wrote:
> > > > Date: 2026-11-05 11:50:19-0500
> > > > From: Steven Rostedt <rostedt@goodmis.org>
> 
> [...]
> 
> > > > Oops, typo, I meant trace_event_filter.c
> > > 
> > > Still not found.
> > > 
> > > 	alx@devuan:~/src/linux/linux/master$ find | grep trace_event_filter.c
> > > 	alx@devuan:~/src/linux/linux/master$ find | grep trace.event.filter
> > > 	alx@devuan:~/src/linux/linux/master$ 
> 
> Besides that the above is yet another "Useless use of grep".

See below (spoiler: not so useless).

> > Oh, you are an oldschool guy :-)

In this sense, yep.  :-)

> > 
> > I can't believe people with Git index available are using `find`
> > and not `git ls-files`. `find` is too slow...
> 
> $ time find . -name trace_events_filter.c
> ./kernel/trace/trace_events_filter.c
> 
> real    0m0.081s
> user    0m0.028s
> sys     0m0.053s
> 
> $ time git ls-files \*trace_events_filter.c
> kernel/trace/trace_events_filter.c
> 
> real    0m0.014s
> user    0m0.010s
> sys     0m0.005s
> 
> $ time git ls-files \*trace_events_filter.c
> kernel/trace/trace_events_filter.c
> 
> real    0m0.014s
> user    0m0.004s
> sys     0m0.010s
> 
> $ time find . -name trace_events_filter.c
> ./kernel/trace/trace_events_filter.c
> 
> real    0m0.083s
> user    0m0.021s
> sys     0m0.063s
> 
> (with IPC to `grep` it will be even slower)

Actually, IPC to grep(1) makes it faster, not slower.  :)
Not only that, but I get to use a regex, which is more comfortable than
a glob for finding stuff.

Even if only for the regex, I find it already worth it, but the better
performance makes it even better.

	$ time find . -name trace_events_filter.c
	./kernel/trace/trace_events_filter.c

	real	0m0.064s
	user	0m0.025s
	sys	0m0.040s
	$ time find . | grep trace_events_filter.c
	./kernel/trace/trace_events_filter.c

	real	0m0.059s
	user	0m0.023s
	sys	0m0.043s
	$ time find . | grep trace_events_filter.c
	./kernel/trace/trace_events_filter.c

	real	0m0.058s
	user	0m0.033s
	sys	0m0.032s
	$ time find . -name trace_events_filter.c
	./kernel/trace/trace_events_filter.c

	real	0m0.070s
	user	0m0.020s
	sys	0m0.050s

About why, I'm not sure if find(1) is slow at filtering, or if having
a separate CPU working on the filtering makes it more powerful (perhaps
both).

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):

	$ time git ls-files | grep trace_events_filter.c
	kernel/trace/trace_events_filter.c

	real	0m0.023s
	user	0m0.018s
	sys	0m0.010s
	$ time git ls-files \*trace_events_filter.c
	kernel/trace/trace_events_filter.c

	real	0m0.016s
	user	0m0.012s
	sys	0m0.004s
	$ time git ls-files \*trace_events_filter.c
	kernel/trace/trace_events_filter.c

	real	0m0.011s
	user	0m0.011s
	sys	0m0.000s
	$ time git ls-files | grep trace_events_filter.c
	kernel/trace/trace_events_filter.c

	real	0m0.023s
	user	0m0.017s
	sys	0m0.012s

Still, the fact that grep(1) is easier to remember than git-ls-files(1)
means that it's worth it for me to pipe to grep(1).  But indeed, using
git-ls-files(1) in this pipeline to replace find(1) might be reasonable.
After all, I don't want to search in temporary files.

BTW, on top of all this, the interface of find(1) is so badly designed
that I can never remember how to use it properly.  Compare that to
piping to grep(1), which everyone knows how to do with eyes closed.

Necessary link when discussing about find(1):
<https://doc.cat-v.org/unix/find-history>
(it's quite fun; recommended read!)


Have a lovely night!
Alex

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