Re: [PATCH 2/3] wildmatch: support "no FNM_PATHNAME" mode

On Thu, Dec 20, 2012 at 12:24 AM, Junio C Hamano [off-list ref] wrote:

When that happens, we should want to retain the same "do not bother
to descend into subdirectories that will never match" optimization
for a pattern like "Doc*tion/**/*.txt".  Because of FNM_PATHNAME, we
can tell if a subdirectory is worth descending into by looking at
the not-so-simple prefix "Doc*tion/"; "Documentation" will match,
"Doc" will not (because '*' won't match '/').

Which tells me that integrating this _well_ into the rest of the
system is not just a matter of replacing fnmatch() with wildmatch().

Yeah, we open a door for more opportunities and a lot more headache.

I also expect that wildmatch() would be much slower than fnmatch()
especially when doing its "**" magic, but I personally do not think
it will be a showstopper.

A potential showstopper is the lack of multibyte support. I don't know
if people want that though.

If the user asks for a more powerful but
expensive operation, we are saving time for the user by doing a more
powerful thing (reducing the need to postprocess the results) and
can afford to spend extra cycles.

In some case we may be able to spend fewer cycles by preprocessing
patterns first.

As long as simpler patterns fnmatch() groks (namely, '?', '*', and
'[class]' wildcards only) are not slowed down by replacing it with
wildmatch(), that is, of course.

I'm concerned about performance vs fnmatch too. I'll probably write a
small program to exercise both and measure it with glibc.
-- 
Duy