Re: Most important QC of the year



In article <xn0eou93ekhw45000@xxxxxxxxxxxxxxxxxxxxxx>, "Roddy Pratt" <>
says...

The odds on your strings having different lengths are
probably similar to the odds on the first characters being different,

Are you sure?

Number of possible string lengths: 2^32
Number of possible first chars: 2^8

It strikes me that the odds of strings being of different lengths is
significantly greater than the odds that they will begin with different
characters - even if you replace the word "possible" with "likely".

;)


Of course, it depends what's being compared - if comparing fixed length
data from a DB, for example, then the strings are guaranteed to have the
same length, but as was pointed out, determining this in advance can be
used to compare them faster anyway.


I don't think this will actually make *significant* improvements in
most cases.

I think it might be surprising to find out just how much difference it
could make.

I have recently conducted a performance focussed review of an area of
functionality in an application that was believed to be as tight and
efficient as possible.

Sure enough, I only managed to squeeze a few extra ms out of key areas
in the particular sub-system. But that sub-system was unexpectedly very
heavily exercised at runtime in the case one particular installation,
and those handfuls of ms in that case added up to a HUGELY significant
performance boost at runtime.

I imagine the same could be true in this case.

As was mentioned, string comparisions are scattered liberally throughout
almost all applications.


What I would like to know is, is there any way to patch the RTL
functions?

i.e. is there some way we could adopt this alternate string comparison
mechanism in our historical code base without having to trawl through
the code and manually replace every sA = sB with IsStrEqual(sA, sB)?


--
Jolyon Smith
.



Relevant Pages

  • Re: Performance RPG Figurative Constants versus Literals
    ... in compilation times between the two methods, ... I would suspect that the compiler would store *blanks as a single byte ... I would also suspect that comparing ... a 132 character string to a figurative constant would be quicker in the ...
    (comp.sys.ibm.as400.misc)
  • Re: A more efficient way
    ... > Is there a more efficient way of comparing a string to different words? ... the limit," 20.17's suggestion leads to hashing schemes which ...
    (comp.lang.c)
  • Re: if question
    ... >> performed before comparing. ... > and boolean is the simplest type. ... Why convert the string to boolean? ...
    (microsoft.public.scripting.jscript)
  • Re: Strange strcmp() action?
    ... "Compares the C string str1 to the C string str2. ... This function starts comparing the first character of each string. ... It doesn't say anything about comparing the terminating null character ...
    (comp.lang.c)
  • Re: (VWST) String includes: compare failure
    ... I don't think your problem is comparing instances of ISO8859L1String and ByteString. ... Contrary to many comparison methods that require that the two objects be of the same class or species, your two string classes need not be the same. ... address read from a POP3 server,the code allways fails to ... (eMailAddresses includes: (item eAddress) ...
    (comp.lang.smalltalk)