From: "Rémi Bernon" Subject: Re: [PATCH 1/2] gdi32/tests: Add locale-dependent face matching test. Message-Id: <79df855e-dee8-4324-65d3-febf5671a039@codeweavers.com> Date: Mon, 23 Nov 2020 15:12:48 +0100 In-Reply-To: <70357432-3b83-570d-ce38-a68e1557dde2@codeweavers.com> References: <20201123122050.490616-1-rbernon@codeweavers.com> <87zh381ad3.fsf@wine> <70357432-3b83-570d-ce38-a68e1557dde2@codeweavers.com> 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 -- Rémi Bernon