Path: utzoo!attcan!uunet!snorkelwacker!apple!mips!sjsca4!poffen From: poffen@sj.ate.slb.com (Russell Poffenberger) Newsgroups: alt.sources.d Subject: Re: Fast strcmp() wanted. Message-ID: <1990Sep27.213253.14178@sj.ate.slb.com> Date: 27 Sep 90 21:32:53 GMT References: <12145@crdgw1.crd.ge.com> <1646@cherry.edc.UUCP> Reply-To: poffen@sj.ate.slb.com (Russell Poffenberger) Organization: Schlumberger Technologies, San Jose, CA. Lines: 37 In article otto@tukki.jyu.fi (Otto J. Makela) writes: >In article <1646@cherry.edc.UUCP> fraser@edc.UUCP (Fraser Orr) writes: > In article <12145@crdgw1.crd.ge.com> larocque@jupiter.crd.ge.com (David M. LaRocque) writes: > >After I profiled my C program I discovered that the function > >strcmp() takes one third of my program's CPU time. I was hoping > >someone may have written their own version of strcmp() that > >outperforms the library's function. > > One quick dirty thing I did once was to change > if (strcmp (a,b)==0) > to > if (*a==*b && (strcmp(a.b)==0)) > > I seem to remember a remarkable performance improvement, like about 5 > times faster. Probably due to the fact that the program mainly did > strcmp and the strcmp was pretty bad. > >This should obviously be: > if(*a==*b && (strcmp(a,b)==0)) >(just in case...) > >I'd believe if your compiler is really brain-damaged, this could also help >a teeny weeny bit: > if(*a==*b && (!strcmp(a,b))) The reason for a performance increase is that statistically, for random strings, more often than not, the first character will not match, so that further checking is not needed. In the example given, this avoids making a function call and the overhead associated with it. Creating inline functions for strcmp type operations (if your compiler supports them) will help a lot by avoiding a function call entirely. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254