From: Ævar Arnfjörð Bjarmason Date: Mon, 26 Feb 2018 12:34:07 GMT Subject: Re: [PATCH 0/2] wildmatch precompilation interface Message-ID: <87muzwdj5s.fsf@evledraar.gmail.com> In-Reply-To: On Mon, Feb 26 2018, Duy Nguyen jotted: > On Mon, Feb 26, 2018 at 3:35 AM, Ævar Arnfjörð Bjarmason > 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. 2. The dir.c use (and some tree-related stuff) are the real hot codepaths using wildmatch. 3. 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.