GNU bug report logs - #34343
[PATCH] Make project--find-regexp-in-files work with remote files

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 34343 <at> debbugs.gnu.org, Felicián Németh <felician.nemeth <at> gmail.com>
Subject: bug#34343: [PATCH] Make project--find-regexp-in-files work with remote files
Date: Mon, 6 Jan 2020 17:33:06 +0300

[Message part 1 (text/plain, inline)]

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.

[tramp-local-name.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.