[patch] syntax:plain for .hgignore

[Jonathan S. Shapiro]

On Tue, 2007-09-11 at 00:24 +0200, Guido Ostkamp wrote:
> Based on the above, I don't think so. Please let us know your opinion.

Unfortunately, these numbers don't tell us anything because they are
running against different python implementations (and possibly different
RE implementations). Is there any chance to measure this running on the
same version of python?

The numbers reported by "time" are notoriously inaccurate.
Unfortunately, this is a case where running the test multiple times
gives a very skewed view, because it will obscure the disk overheads
that (in the real world) probably dominate this situation. Still, it is
worth a try if our goal is to understand the pure RE overhead. Try
running each test 5 times and send the numbers from the last run.

The "user" number for filled repository with RE's is quite bad, but
without a stable run we don't know if it's an anomaly and we still don't
really know why it is happening. Even if we choose to add plain, I want
to understand the root cause here.

Without seeing your .hgignore file, I can only speculate, but here is my
suspicion about it: (1) the .hgignore entries have many long common
prefixes, such as:

   foo/bar/baz/bletch/file1.c
   foo/bar/baz/bletch/file2.c

and (2) the RE engine is generating compiling a back-tracking RE for
some reason.


Ultimately, however, you still have not addressed my main concern with
this, which is that we are going to have to undo this when
include/exclude is done. Even if the benefit here is real, it does not
seem worthwhile if we just going to have to throw it out in the next
release. I would rather try to find a way to make the RE mechanism
faster here.
-- 
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org