> 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, -- Adam Strzelecki |: nanoant.com :|
