Path: utzoo!utgpu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!sun-barr!newstop!exodus!peregrine!falk From: falk@peregrine.Sun.COM (Ed Falk) Newsgroups: alt.sources Subject: Re: Fast strcmp() wanted. Message-ID: <1145@exodus.Eng.Sun.COM> Date: 4 Oct 90 21:03:47 GMT References: <1646@cherry.edc.UUCP> <1990Sep27.151543.8025@ccs.carleton.ca> <6003@hplabsz.HPL.HP.COM> Sender: news@exodus.Eng.Sun.COM Organization: Sun Microsystems, Mt. View, Ca. Lines: 29 In article <6003@hplabsz.HPL.HP.COM> sartin@hplabs.hp.com (Rob Sartin) writes: >In article cedman@lynx.ps.uci.edu (Carl Edman) writes: >>string structure (or better class, long live C++ ! :-) which calculates >>a 32-bit CRC for each string the first time and stores it somewhere. >>Then only 1 (inlined) longword-compare will do the stringcomparisons >>for you. > >Afraid not. It'll give you an estimate of whether the strings match >(correctly identifying those that don't). You will need to then >actually compare the strings if they are the same. This method will >also be unable to reproduce strcmp's behavior (strcmp returns a signed >result indicated the <, =, > by being negative, zero, positive), it will >only return a boolean (match, no match). Also, these two strings "ab\0x" "ab\0y" (where x and y are any garbage that happens to be in memory after the terminating '\0') will be evaluated as unequal. There are workarounds for both problems, of course, but I think there won't be much of a performance improvement after you've done all it requires to get it right. -ed falk, sun microsystems sun!falk, falk@sun.com card-carrying ACLU member.