[PATCH 3 of 8] ignore: add ui to ignore stack

Martin von Zweigbergk martinvonz at google.com
Mon May 18 04:12:45 CDT 2015


OK, so that argument didn't fly. How about this:

I agree that the matcher logic needs to be fast in general, but how often
will this particular matcher be called? My guess is that it's only on
untracked files and directories (but not on files inside ignored
directories). Is that correct? How many such files and directories will
reasonably exist? (That last question wasn't rhetorical; I'd be happy to
hear if you can find out.)

Do we at least agree about the UI problem in having a config option that
makes the user say they're using sane regexes? I don't think it's a huge
problem, but I think it's large enough to do some profiling with hgwatchman
on a realistic working copy (and maybe a "worst-case" one).

On Sun, May 17, 2015, 20:12 Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 05/16/2015 02:18 AM, Martin von Zweigbergk wrote:
> > As mentioned elsewhere, I and the other Martin would really like to see
> > if we can afford (performance-wise) to replace pattern-rewriting with
> > application of the pattern to a substring. It just seems like the right
> > thing to do from the user's point of view. At least if done in C and
> > avoiding string copying, it doesn't seem like a terribly expensive
> > operation. What else is done in this code path? Stat'ing the files?
> > Listing files in directory? Seems like that should be more expensive,
> > but maybe not on warm disk?
>
> With watchman, the disk is rarely touched directly.
>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150518/39d272c3/attachment.html>


More information about the Mercurial-devel mailing list