GNU bug report logs - #17229
[PATCH 2/2] grep: speed-up by using memchr() in Boyer-Moore searching

Previous Next

Package: grep;

Reported by: Norihiro Tanaka <noritnk <at> kcn.ne.jp>

Date: Wed, 9 Apr 2014 13:56:02 UTC

Severity: normal

Tags: moreinfo, patch

Done: Norihiro Tanaka <noritnk <at> kcn.ne.jp>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 17229 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Norihiro Tanaka <noritnk <at> kcn.ne.jp>, 17229 <at> debbugs.gnu.org
Subject: Re: bug#17229: [PATCH 2/2] grep: speed-up by using memchr() in
 Boyer-Moore searching
Date: Wed, 09 Apr 2014 17:35:31 -0700
[Message part 1 (text/plain, inline)]
On 04/09/2014 06:54 AM, Norihiro Tanaka wrote:
> memchr() of glibc is faster than seeking by delta1 on some platforms.
> So, when there is no chance to match for a while, use it on them.
>
> Speed-up about 3x in best case, 10% in normal case by this patch.
>
> It's still available only for x86 and x86-64 platform.
>

Thanks, I have some questions about this one.

What benchmark did you use to time this?

THe patch refers to a variable called 'trans' that is not in the current 
savannah git master.  Is there some other patch that establishes this 
variable, a patch that is a prerequisite for this one?  If trans is a 
cached copy of kwset->trans, isn't that guaranteed to be NULL here?

What is delta1?  It's mentioned in a comment but not in the code.

It'd be simpler to use memchr on all platforms; is there a major 
performance downside to that?  For example, what about the attached 
patch instead?  It also simplifies things a bit to avoid a label and its 
associated gotos, under the assumption that trans is NULL here.
[memchr.diff (text/x-patch, attachment)]

This bug report was last modified 11 years and 105 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.