From: "Rémi Bernon" Subject: Re: [PATCH 1/2] gdi32/tests: Add locale-dependent face matching test. Message-Id: Date: Mon, 23 Nov 2020 15:24:48 +0100 In-Reply-To: <79df855e-dee8-4324-65d3-febf5671a039@codeweavers.com> References: <20201123122050.490616-1-rbernon@codeweavers.com> <87zh381ad3.fsf@wine> <70357432-3b83-570d-ce38-a68e1557dde2@codeweavers.com> <79df855e-dee8-4324-65d3-febf5671a039@codeweavers.com> On 11/23/20 3:12 PM, Rémi Bernon wrote: > On 11/23/20 2:40 PM, Rémi Bernon wrote: >> On 11/23/20 2:16 PM, Alexandre Julliard wrote: >>> Rémi Bernon writes: >>> >>>> Signed-off-by: Rémi Bernon >>>> --- >>>> >>>> This brings another ~200ms prefix startup time improvement, from ~1.2s >>>> to ~1s for "wine cmd /c exit" execution time on average, as well as a >>>> ~50ms process startup time improvement, from ~0.25s to ~0.2s execution >>>> time when prefix is already started. >>>> >>>> The test shows that using wcsicmp is incorrect for face name >>>> comparison, >>>> or at least that we should not rely on the current locale, and perf >>>> also reports a high number of CPU cache miss coming from the locale >>>> refcounting, which is the main source of improvement here. >>>> >>>> IIUC RtlDowncaseUnicodeChar also does locale dependent case folding, >>>> but I'm not sure to see how it's controlled (it's the system default >>>> locale that defines the loaded tables right?), and we should probably >>>> check if case matching depends on it. If not, is there any canonical >>>> normalized unicode case folding that should be used instead? >>> >>> Unicode case mapping in ntdll is not locale-dependent. You can use >>> CompareStringOrdinal() for that sort of thing. >>> >> >> I also wanted to avoid iterating the whole strings as much as >> possible. RtlCompareUnicodeStrings (and so CompareStringOrdinal too) >> needs the actual strings length, or at least one of the two strings >> length to stop the iteration. This starts to add up as these >> comparisons are done quite a lot, specially when there's a lot of fonts. >> >> Using CompareStringOrdinal, with strlenW calls to get the actual >> lengths, instead adds ~50ms to the results above when prefix is not >> start, and ~15ms to the process execution time when prefix is already >> started. >> >> Of course the results depends on how many system fonts are installed, >> and I'm testing it with the debian fonts-noto package which brings a >> lot, but I don't think it's so unusual (I didn't even install it for >> the test, for some reason I've got it installed for a while). > > Well nevermind, it looks like that RtlCompareUnicodeStrings should > support -1 length and stop the comparison on first EOS, according to: > >   https://testbot.winehq.org/JobDetails.pl?Key=82338 Or not, it just compares lengths... so what I initially said. -- Rémi Bernon