■ Win32 case-insensitive string comparison performance

xplorer² spends a lot of its time comparing filename paths, which under windows filesystem are case insensitive. I wanted to see whether there is any significant difference in the CPU speed using various methods, e.g. straight lstrcmpi or upfront lowercase conversion with CharLower followed by case sensitive comparison (memcmp). What do you think?




#define LOOPS 500000
WCHAR buf[1000], other[1000];
// fill buf[] with mixed-case filenames
// second buffer identical but UPPERCASE
lstrcpy(other, buf);
CharUpper(other);

int i = LOOPS;
while(i--)
   // case insensitive comparison
   lstrcmpi(buf, other);
      

// option 2: upfront case conversion
WCHAR lo1[1000], lo2[1000];
int i = LOOPS;
while(i--) {
   memcpy(lo1, buf, 2*(len+1));
   CharLower(lo1);
   memcpy(lo2, other, 2*(len+1));
   CharLower(lo2);
   memcmp(lo1, lo2, 2*(len+1));
}

Although the second listing looks heavier, involving copying, converting and comparing the 2 strings, it is actually faster than the first! Using UNICODE strings it doesn't matter whether we're having Greek or English filenames, the results are roughly the same.

I couldn't do this experiment with Chinese names because apparently the language doesn't do upper/lower case (?)

Here are the CPU timings, using the same 314 character-long string (repeated 500000 times to get significant timings) under various circumstances:

Case	lstrcmpi	CharLower
x86 build	1043 ms	859 ms
64 bit	1056 ms	737 ms

Table 1. CPU times (millisec) for case insensitive string comparisons

The second approach combining lowercase conversion and the super-fast memcmp function is 30% faster in 64 bit code, including the copying overhead. Unexpected to say the least! Of course, in the general case where the strings compared are different, lstrcmpi will stop well short of the full length, whereas converting the entire string to lowercase upfront (option #2) would be clearly a waste of effort. On the other hand converting to lowercase is a necessary step anyway if one plans to do wildcard pattern matching.

Naturally xplorer² isn't doing string comparisons all the time, never mind half a million of them in a row, so here's another instance of striving for excellence, saving the last drop of CPU power, which turns out to be not really important, as we have seen time and again in this blog series...

ps. Happy new year!