Re: file-remote-p being called too often?

Re: file-remote-p being called too often?

[David Ponce]

> this is with emacs built from Git@HEAD:
> Discovered while profiling code in *scratch* via profiler-report:
> 
> It looks like file-remote-p gets called from a timer (not started by e)
> and that that function shows up as being one of the ones eating cycles.

I wonder if the problem could be due to recentf if the option
`recentf-auto-cleanup' is enabled to cleanup the recentf list each
time Emacs has been idle during N seconds?

Because in this case, the function `recentf-cleanup' is called every N
seconds, in turn calling `recentf-keep-p' to checks if a file name
should be kept in the recentf list based on the `recentf-keep' option,
whose default value is the predicate `recentf-keep-default-predicate'
that uses `file-remote-p':

(defun recentf-keep-default-predicate (file)
   "Return non-nil if FILE should be kept in the recent list.
It handles the case of remote files as well."
   (cond
    ((file-remote-p file nil t) (recentf-access-file file))
    ((file-remote-p file))
    ((file-readable-p file))))

Regards

RE: [External] : Re: file-remote-p being called too often?

[Drew Adams]

Thanks for noticing this!  I myself use
the default value of `mode' for option
`recentf-auto-cleanup', so I don't run
into the problem.

But it seems that a number value (idle
N seconds) is really something to at
least warn about, and maybe discourage,
especially given the default value of
`recentf-keep'.

Those two are a deadly mix, calling
`file-remote-p' every N secs -- unless
N is _very_ large.

I'm surprised this hasn't been reported
before (if it hasn't).

Re: file-remote-p being called too often?

[T.V Raman]

good catch, will chase that down.

David Ponce writes:
 > > this is with emacs built from Git@HEAD:
 > > Discovered while profiling code in *scratch* via profiler-report:
 > > 
 > > It looks like file-remote-p gets called from a timer (not started by e)
 > > and that that function shows up as being one of the ones eating cycles.
 > 
 > I wonder if the problem could be due to recentf if the option
 > `recentf-auto-cleanup' is enabled to cleanup the recentf list each
 > time Emacs has been idle during N seconds?
 > 
 > Because in this case, the function `recentf-cleanup' is called every N
 > seconds, in turn calling `recentf-keep-p' to checks if a file name
 > should be kept in the recentf list based on the `recentf-keep' option,
 > whose default value is the predicate `recentf-keep-default-predicate'
 > that uses `file-remote-p':
 > 
 > (defun recentf-keep-default-predicate (file)
 >    "Return non-nil if FILE should be kept in the recent list.
 > It handles the case of remote files as well."
 >    (cond
 >     ((file-remote-p file nil t) (recentf-access-file file))
 >     ((file-remote-p file))
 >     ((file-readable-p file))))
 > 
 > Regards

-- 

Re: file-remote-p being called too often?

[T.V Raman]

I checked, I dont have recentf-mode enabled, but I went ahead and set
auto-cleanup to never.

David Ponce writes:
 > > this is with emacs built from Git@HEAD:
 > > Discovered while profiling code in *scratch* via profiler-report:
 > > 
 > > It looks like file-remote-p gets called from a timer (not started by e)
 > > and that that function shows up as being one of the ones eating cycles.
 > 
 > I wonder if the problem could be due to recentf if the option
 > `recentf-auto-cleanup' is enabled to cleanup the recentf list each
 > time Emacs has been idle during N seconds?
 > 
 > Because in this case, the function `recentf-cleanup' is called every N
 > seconds, in turn calling `recentf-keep-p' to checks if a file name
 > should be kept in the recentf list based on the `recentf-keep' option,
 > whose default value is the predicate `recentf-keep-default-predicate'
 > that uses `file-remote-p':
 > 
 > (defun recentf-keep-default-predicate (file)
 >    "Return non-nil if FILE should be kept in the recent list.
 > It handles the case of remote files as well."
 >    (cond
 >     ((file-remote-p file nil t) (recentf-access-file file))
 >     ((file-remote-p file))
 >     ((file-readable-p file))))
 > 
 > Regards

-- 

Re: file-remote-p being called too often?

[T.V Raman]

As one more means to chasing down the culprit:

mM-x debug-on-entry
file-remote-p

Above gets invoked when emacspeak plays a local audio file as an earcon
using a shell command; there should be no reason to run file-remote-p in
this case.

Debugger entered--entering a function:
* (file-remote-p "/home/raman/emacs/lisp/emacspeak/sounds/" localname)
  (file-local-name "/home/raman/emacs/lisp/emacspeak/sounds/")
  (executable-find "pactl")
  (emacspeak-sounds-get-file process-active)
  (emacspeak-play-auditory-icon process-active)
  (emacspeak-auditory-icon process-active)
  (emacspeak-speak-mode-line nil)
  (#<subr funcall-interactively> emacspeak-speak-mode-line nil)
  (apply #<subr funcall-interactively> emacspeak-speak-mode-line nil)
  (ad-Advice-funcall-interactively #<subr funcall-interactively> emacspeak-speak-mode-line nil)
  (apply ad-Advice-funcall-interactively #<subr funcall-interactively> (emacspeak-speak-mode-line nil))
  (funcall-interactively emacspeak-speak-mode-line nil)
  (#<subr call-interactively> emacspeak-speak-mode-line nil nil)
  (apply #<subr call-interactively> emacspeak-speak-mode-line (nil nil))
  (call-interactively@ido-cr+-record-current-command #<subr call-interactively> emacspeak-speak-mode-line nil nil)
  (apply call-interactively@ido-cr+-record-current-command #<subr call-interactively> (emacspeak-speak-mode-line nil nil))
  (call-interactively emacspeak-speak-mode-line nil nil)
  (command-execute emacspeak-speak-mode-line)

-- 

Re: file-remote-p being called too often?

[T.V Raman]

global-auto-revert-mode also appears to trigger file-remote-p -- that
would be one example where the call could be usefully memoized.

-- 

Re: file-remote-p being called too often?

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>,  Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 17 Jan 2024 13:18:09 -0800
> 
> Above gets invoked when emacspeak plays a local audio file as an earcon
> using a shell command; there should be no reason to run file-remote-p in
> this case.
> 
> Debugger entered--entering a function:
> * (file-remote-p "/home/raman/emacs/lisp/emacspeak/sounds/" localname)
>   (file-local-name "/home/raman/emacs/lisp/emacspeak/sounds/")
>   (executable-find "pactl")
>   (emacspeak-sounds-get-file process-active)
>   (emacspeak-play-auditory-icon process-active)
>   (emacspeak-auditory-icon process-active)
>   (emacspeak-speak-mode-line nil)

Why does emacspeak repeatedly call executable-find, and from a
mode-line format on top of that?  Why not call executable-find just
once, and then store the result in some variable, to be reused on
subsequent calls from emacspeak-speak-mode-line?

In any case, for local file names, such as "pactl", the call to
file-remote-p should be very inexpensive.  Do you have a reason to
believe it is somehow expensive in your case?  Or did you just wonder
why file-remote-p is called that often, regardless of whether it's
expensive?  The reason for frequent calls seems to be that you have
this call in your mode-line-format, which is not a good design.  This
design means executable-find will be called every redisplay cycle,
time and time again, for the same program name, which is hardly a good
idea.

Re: file-remote-p being called too often?

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>,  Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 17 Jan 2024 13:56:44 -0800
> 
> global-auto-revert-mode also appears to trigger file-remote-p -- that
> would be one example where the call could be usefully memoized.

Michael will tell, but I don't think this can be memoized, since file
handlers can change dynamically behind autorevert's back.

AFAIU, autorevert calls file-remote-p only when there are
notifications about changes in some visited files, so when Emacs is
idle it should not call file-remote-p due to global-auto-revert-mode.

Re: file-remote-p being called too often?

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

>> global-auto-revert-mode also appears to trigger file-remote-p -- that
>> would be one example where the call could be usefully memoized.
>
> Michael will tell, but I don't think this can be memoized, since file
> handlers can change dynamically behind autorevert's back.

Indeed. And even if it would be only Tramp's file name handler, this
cannot be memoized, because remote file name syntax can change on the
fly. See command `tramp-change-syntax'.

And I also ask the same question as Eli: How expensive is a single
`file-remote-p' call? In the Tramp case it is designed to avoid going
remote unless a remote connection is already established. And if the
file name in question does not match the remote file name syntax, it
returns nil almost immediately.

Best regards, Michael.

Re: file-remote-p being called too often?

[T.V Raman]

thanks for the executable-find tip, yes I shall update  to cache the
value



Eli Zaretskii writes:
 > > From: "T.V Raman" <raman@google.com>
 > > Cc: Emacs Devel <emacs-devel@gnu.org>,  Eli Zaretskii <eliz@gnu.org>
 > > Date: Wed, 17 Jan 2024 13:18:09 -0800
 > > 
 > > Above gets invoked when emacspeak plays a local audio file as an earcon
 > > using a shell command; there should be no reason to run file-remote-p in
 > > this case.
 > > 
 > > Debugger entered--entering a function:
 > > * (file-remote-p "/home/raman/emacs/lisp/emacspeak/sounds/" localname)
 > >   (file-local-name "/home/raman/emacs/lisp/emacspeak/sounds/")
 > >   (executable-find "pactl")
 > >   (emacspeak-sounds-get-file process-active)
 > >   (emacspeak-play-auditory-icon process-active)
 > >   (emacspeak-auditory-icon process-active)
 > >   (emacspeak-speak-mode-line nil)
 > 
 > Why does emacspeak repeatedly call executable-find, and from a
 > mode-line format on top of that?  Why not call executable-find just
 > once, and then store the result in some variable, to be reused on
 > subsequent calls from emacspeak-speak-mode-line?
 > 
 > In any case, for local file names, such as "pactl", the call to
 > file-remote-p should be very inexpensive.  Do you have a reason to
 > believe it is somehow expensive in your case?  Or did you just wonder
 > why file-remote-p is called that often, regardless of whether it's
 > expensive?  The reason for frequent calls seems to be that you have
 > this call in your mode-line-format, which is not a good design.  This
 > design means executable-find will be called every redisplay cycle,
 > time and time again, for the same program name, which is hardly a good
 > idea.

-- 

Re: file-remote-p being called too often?

[T.V Raman]

how expensive? dont know yet, I was following up on why it was showing
up as significant when profiling.


Michael Albinus writes:
 > Eli Zaretskii <eliz@gnu.org> writes:
 > 
 > Hi,
 > 
 > >> global-auto-revert-mode also appears to trigger file-remote-p -- that
 > >> would be one example where the call could be usefully memoized.
 > >
 > > Michael will tell, but I don't think this can be memoized, since file
 > > handlers can change dynamically behind autorevert's back.
 > 
 > Indeed. And even if it would be only Tramp's file name handler, this
 > cannot be memoized, because remote file name syntax can change on the
 > fly. See command `tramp-change-syntax'.
 > 
 > And I also ask the same question as Eli: How expensive is a single
 > `file-remote-p' call? In the Tramp case it is designed to avoid going
 > remote unless a remote connection is already established. And if the
 > file name in question does not match the remote file name syntax, it
 > returns nil almost immediately.
 > 
 > Best regards, Michael.

-- 

Re: file-remote-p being called too often?

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Date: Thu, 18 Jan 2024 06:44:48 -0800
> Cc: eliz@gnu.org,
>     raman@google.com,
>     da_vid@orange.fr,
>     emacs-devel@gnu.org
> 
> how expensive? dont know yet, I was following up on why it was showing
> up as significant when profiling.

Significant in terms of cpu percentage?  How many percents?

Re: file-remote-p being called too often?

[T.V Raman]

about 16% from memory but was sampled over a relatively short time
while i debugged something else


Eli Zaretskii writes:
 > > From: "T.V Raman" <raman@google.com>
 > > Date: Thu, 18 Jan 2024 06:44:48 -0800
 > > Cc: eliz@gnu.org,
 > >     raman@google.com,
 > >     da_vid@orange.fr,
 > >     emacs-devel@gnu.org
 > > 
 > > how expensive? dont know yet, I was following up on why it was showing
 > > up as significant when profiling.
 > 
 > Significant in terms of cpu percentage?  How many percents?

-- 

Re: file-remote-p being called too often?

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Date: Thu, 18 Jan 2024 07:57:41 -0800
> Cc: raman@google.com,
>     michael.albinus@gmx.de,
>     da_vid@orange.fr,
>     emacs-devel@gnu.org
> 
> about 16% from memory but was sampled over a relatively short time
> while i debugged something else

16% doesn't sound too bad.