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

From: Fredrik Kuivinen <frekui@gmail.com>
Date: Feb 14, 2010, 16:47 UTC
Message-ID: <4c8ef71002140847i19b64b21ocfa71658a49d97b5@mail.gmail.com>
In-Reply-To: <7vk4uhklxm.fsf@alter.siamese.dyndns.org>

On Sat, Feb 13, 2010 at 19:52, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> Fredrik Kuivinen <frekui@gmail.com> 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.

Show 6 quoted lines

> 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