Home » Blog
date 3.Jan.2023

■ 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:

Caselstrcmpi  CharLower
x86 build   1043 ms859 ms
64 bit 1056 ms737 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!

Post a comment on this topic »

Share |

©2002-2023 ZABKAT LTD, all rights reserved | Privacy policy | Sitemap