kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings
rob at codeweavers.com
Fri Feb 29 11:06:02 CST 2008
Adam Strzelecki wrote:
> During playing with installing Visual Studio 2005 with WINE I found
> out that WINE's MSI is spending lot of time inside lstrcmpW. With Mac
> OS X process sampler I checked that actually 60-70% of CompareStringW
> is wine_compare_string, rest is rest of function body, which is in
> case 2 strlenW calls (inline).
> I believe this isn't necessary, moreover most of compares in MSI are
> non-matching on first few characters, however with current
> implementation we go trough all strings with strlenW regardless of
> anything, which is waste in CPU cucles.
> I modified both CompareStringW and wine_compare_string so they work
> with -1 strings without strlenW checking before.
> This saves in my testing about 20-30% of CPU cycles.
You introduce a lot of complexity into the low-level helper routines. We
don't want to put Win32 quirks, like -1 meaning "until the null
terminator" being put into the low-level functions unless we have to. In
this case, if this is the sole cause of the slowdown then you would be
better off caching the length at the MSI level since the strings are
bound to be accessed more than once.
However, I think you'll find that this is an algorithm problem in MSI
rather than a performance issue in the functions you mention. By that, I
mean it is likely that one MSI query is being performed again and again
and that the results should be cached.
> Note also that WINE's strlenW and lstrcmpW functions are far from
> perfect. Normal msvcrt or glibc string functions are far more
> optimized at machine code level. This makes strong impact on WINE
> parts strongly relaying on string manipulation which is in this case MSI.
How do you know that the compiler isn't generating the same assembly for
the functions as that used by msvcrt / glibc? Theories like these need
numbers to back them up.
More information about the wine-devel