Re: [PATCH 0/5] Speed up string search routines

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 0/5] Speed up string search routines

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:48:14

Fredrik Kuivinen [off-list ref] writes:
This series speeds up git grep and pickaxe by using the string search
routines from GNU grep.
Thanks.

It needs to be a bit more friendly to readers of "git log" and
ReleaseNotes by hinting why use of kwset is beneficial (e.g. "use kwset
instead of memmem to find fixed string more efficiently") in the commit
titles.

The preference of using GPLv2 version was already mentioned by a few
people.

Shouldn't obstack.[ch] be in compat/ so that people on platforms where
they are natively available do not have to compile our own copies?

It is somewhat curious that you gave numbers for only negative case in
pickaxe test and numbers for only positive case in grep test.  Does this
conversion have some interesting performance charasteristics such as
penalizing positive-match case to speed up negative-match case or vice
versa (the earlier "grep lookahead" work had that effect, even though the
downside was really small)?

Re: [PATCH 0/5] Speed up string search routines

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

On Sat, Feb 13, 2010 at 19:52, Junio C Hamano [off-list ref] wrote:
Fredrik Kuivinen [off-list ref] writes:

It needs to be a bit more friendly to readers of "git log" and
ReleaseNotes by hinting why use of kwset is beneficial (e.g. "use kwset
instead of memmem to find fixed string more efficiently") in the commit
titles.
Will fix in the next iteration.
Shouldn't obstack.[ch] be in compat/ so that people on platforms where
they are natively available do not have to compile our own copies?
There is code in obstack.c to check if we are using gnu libc or not.
If gnu libc is used, then ELIDE_CODE is defined and no code from
obstack.c is compiled.
It is somewhat curious that you gave numbers for only negative case in
pickaxe test and numbers for only positive case in grep test.  Does this
conversion have some interesting performance charasteristics such as
penalizing positive-match case to speed up negative-match case or vice
versa (the earlier "grep lookahead" work had that effect, even though the
downside was really small)?
I did some more benchmarking. In the extreme case when we are looking
for ' ' (i.e., a single space) with pickaxe the new code is actually
slightly slower than the old one.

before:

$ time git log -S' ' > /dev/null

real	0m32.908s
user	0m32.258s
sys	0m0.652s

after:

$ time ./git-log -S' ' > /dev/null

real	0m34.072s
user	0m33.418s
sys	0m0.656s

However, with longer strings the new code wins (the new code wins when
we are searching for two spaces).

grep gets a significant performance increase for all strings I have
tried, it doesn't matter if there are no matches or a lot of matches.

Thanks for the comments.

- 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