Hi Michael,

On 03.01.2020 11:28, Michael Albinus wrote:

> Yes. But in case you want to be generic (handling all possible remote
> file names, not only the Tramp implementation), you must use the file
> name handler implementation, as it is described in
> (info "(elisp) Magic File Names")

As I've shown before, the generic dispatch is far from being the 
bottleneck at the moment. tramp-file-name-handler doing a lot of 
unrelated work is what takes the most time.

> In case you want to go your own path, I could provide you an own
> tramp-file-local-name function, which bypasses this mechanism:

Thank you. I see you've already pushed this function to the release branch.

I could use it like this, sure, but we can have a significant 
performance improvement and keep the generic-ness at the same time.

The simplest option is below. It works fast enough in my testing (*); a 
bit slower than calling tramp-file-local-name directly, but not by much. 
Certainly much faster than the current state of affairs.

It's a bit messy, but I'm not sure how to structure the resulting 
function best. There are several ways, though. What do you think?

(*) The 1'000'000 files example was an extreme one, to optimize for when 
files are local. The 10'000 file project is a real one, on the other hand.

P.S. BTW, I think our convention is not to call save-match-data unless 
obviously required. If the caller needs to save the match data, it will 
use it itself.