On Mon, Feb 26 2018, Duy Nguyen jotted:
> On Mon, Feb 26, 2018 at 3:35 AM, Ævar Arnfjörð Bjarmason
> <avarab@xxxxxxxxx> wrote:
>> My recently landed wildmatch test series was in preperation for some
>> more major wildmatch changes.
>>
>> Here's another series that prepares for bigger changes in wildmatch,
>> it adds an interface to pre-compile the patterns. Right now there's no
>> point in doing this, and it's harmless since none of the codepaths are
>> that performance sensitive, but down the line this'll save us time as
>> we'll be able to skip re-parsing the pattern each time with a better
>> wildmatch backend.
>
> I don't see any big problem with this, but should this be a standalone
> series? Some changes look harmless now, but I'd rather see the real
> precompile implementation to see how it impacts (or benefits) the
> converted call sites.
Let's drop this for now sinceyou're on the fence about it, I wasn't all
that sure myself and thought I'd send it in for comments.
I don't have anything ready for submission from the rest of this series,
but figured (if you/others didn't mind) that it might be easier to
review the addition of the interface at first, but indeed, on second
thought that doesn't make sense.
The state of what I have is:
1. <this tiny series>
2. <WIP add the wildmatch compile interface to more stuff, notably dir.c>
The dir.c use (and some tree-related stuff) are the real hot
codepaths using wildmatch.
3. <WIP Replace the wildmatch backend with syntax-compatible PCRE>
This is somewhat of a mess right now. Preliminary tests reveal that
the pathological case tested for by t/perf/p0100-globbing.sh is
wildly faster, but that most regular matching is a bit slower,
although that might be me being stupid with the interface.
