Brendan Shanks spotted the performance regression in FindFirstFile at least on MacOS for the case when a mask selects no or a few files from a large directory which was triggered by my commit 68fecd77eb103b6a6cfa53f8de559fb28b29b7b6 ("kernelbase: Duplicate file name matching code for FindNextFileW().). That happens because before the commit file filtering by name was done before querying all the file attributes and with the commit the whole full directory contents is read and then filtered in kernelbase. At times it wasn't clear to me how else that could be implemented, but now Brendan found some clues ([1], [2]) which directly suggest that. That documentation omits a lot of essential details about how that matching actually works but gives direction and useful clues.
The last patch essentially reverts the referenced commit although leaves the functionality which it was needed for and, in fact, removes all the wine_todo's from FindFirstFile file name matching tests.
1. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/0b03464...
2. http://ubiqx.org/cifs/rfc-draft/draft-leach-cifs-v1-spec-02.html#s3.3