Thread (5 messages) flat view 5 messages, 4 authors, 2016-06-15

Re: [PATCH] grep: do not do external grep on skip-worktree entries

From: Fredrik Kuivinen <hidden>
Date: 2016-06-15 22:48:00

Possibly related (same subject, not in this thread)

[Resending as the first copy didn't reach the list.]

On Mon, Jan 11, 2010 at 07:39, Junio C Hamano [off-list ref] wrote:
Linus Torvalds [off-list ref] writes:
quoted
It doesn't matter. Since we do the line-by-line thing, the input is always
so short that DFA vs NFA vs BM vs other-clever-search doesn't matter.
There is no scaling - the grep buffer tends to be too small for the
algorithm to matter.

And the reason we do things line-by-line is that we need to then output
things line-per-line.
Here is an experimental patch; first, some numbers (hot cache best of 5 runs).
I get some very unexpected results with this patch. (best of 5 runs):

before:

time git grep --no-ext-grep qwerty
drivers/char/keyboard.c:        "qwertyuiop[]\r\000as"
         /* 0x10 - 0x1f */

real 0m3.531s
user 0m3.056s
sys 0m0.468s

after:

time git grep --no-ext-grep qwerty
drivers/char/keyboard.c:        "qwertyuiop[]\r\000as"
         /* 0x10 - 0x1f */

real    0m4.794s
user    0m4.380s
sys    0m0.404s

with external grep:
time git grep qwerty
drivers/char/keyboard.c:        "qwertyuiop[]\r\000as"
         /* 0x10 - 0x1f */

real    0m1.236s
user    0m0.668s
sys    0m0.544s


So, if I haven't messed up the benchmark, it seems that Junio's patch
makes things go _slower_. I don't understand at all why I get these
results...

This is on a laptop with an Intel T2080 processor running Ubuntu 9.10.

Any ideas on how this can be explained?

- Fredrik
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help