Wine already had at some point strlen along with some other string functions implemented in asm, however they have been removed after it was proved that gcc optimized C code outperforms it.
Let me ask this way, why Wine don't use standard C library functions for lstringsomething kernel32 implementation? Current GLIBC, OSX LIBC are Unicode libraries since quite long time. Is Wine supposed to work on platforms where wchar_t is unimplemented or differs from unsigned short? Anyway AFAIK Wine is only Intel (LittleEndian) 32-bit. So why Wine does re-implement all the string manipulation functions that are already present in C runtimes (heavily optimized for GCC and OS). I know that some of Windows functions differ, but Wine may keep just the implementation of those that differ? What do you think?
You are welcome to show the results of the benchmark which show how much your patch improves performance.
Please have a look at my patch, is just an easiest try to remove IMHO unnecessary requirement to count null-terminated string lengths before comparison, as most of comparisons are made with null-terminated strings (-1 length).
I don't want anyone to accept my patch straight-ahead, but just to review this string manipulation matter in Wine. Probably the best way it would be to have CompareStringW having to versions (function branches), one for 2 null-terminated params (most of cases), 2nd for one, or two strings with named length.
Regards,