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

[Michael Albinus <michael.albinus@gmx.de>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hi Michael,

Hi Dmitry,

> 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.

It might be unrelated to yozur use case. But tramp-file-name-handler is
the central heart of Tramp's file name handling. It ensures that the
proper function is called; that a Tramp subpackage is autoloaded if
needed; that there are no blocking situations due to simultaneous
invocations from timers, filters, sentinels; that there are no
unintended infloops; that Tramp events and errors are caught etc pp. In
the Tramp repository, it is also responsible for thread handling. All of
this must be applied for every file name operation, also for
file-remote-p, even if you don't need some of this in your use case.

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

That's why I have provided this function. In order to avoid a call of
file-local-name (which implies the call of file-remote-p).

> 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?

No. file-remote-p must pass the whole machinery. It isn't called only
for your use case.

And if we start such bypassing for a file name operation, we will end in
unmaintainability soon. Over the years, there has been often the
temptation to bypass this or that file name operation, similar to your
approach. Sometimes I even did, but soon I have reverted such
exceptions. Tramp isn't maintainable any longer, if we introduce such
coding style. Subtle errors you have no idea where they come from.

In general, there's no problem calling tramp-file-name-handler, because
the remote operations take much more time. This machinery is neglectable
then. Your use case is different, because you do not trigger any remote
operation.

> 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.

Well, as you might have seen with my recent commit in master, I intend
to use tramp-file-local-name internally. At some places it seems to be
necessary to protect match data.

Well, I will analyze all these calls, and maybe there are only one or
two places. In this case I can remove save-match-data from the function,
and apply it directly where needed. Let's see.

Best regards, Michael.