The author quickly moves on after finding that expand-file-name is the issue and routes around the problem. The last time we hear from it is when it is patched out. But what is really going on?
The problem is that many parts of Emacs and libraries built on top of them have not been made fully TRAMP aware. There is an abstraction boundary that is being crossed, assumptions are being violated, etc. because all paths are treated equally, despite the fact that most parts of Emacs can identify that a path is remote (or could be remote).
Fixing the underlying issue and providing latency aware variants of commands is not easy (you usually can't just run elisp on a remote machine), but when we get there Emacs will be even more powerful!
Here is an excerpt from some notes I made back in October.
Consider these cases.
I have 10k files that I want to move on a remote server.
I have 10k files that I want to move on a local server.
Where do I put the for loop?
I want to put it so that I only have to call ssh once.
Similar issue with using find and subshells.
If I have to invoke a subshell there is significant overhead.
Having even a little bit of knowledge about the latency of
running a single command, or the knowledge that certain commands
commute under loop reordering would make it much easier to
produce efficient code, basically
#+begin_src elisp
(do-for-values value '(a b c d e f g)
(please-do-this-on-the-remote #'command value))
#+end_src
should be rewritten to
#+begin_src elisp
(please-do-this-on-the-remote
(do-for-values value '(a b c d e f g)
(command value)))
#+end_src
However, this is only safe if the values are from the local and not the remote
and are not functions that are dependent on local state (that doesn't really
matter in strict languages though).
The best way to approach this might be to detect and warn before running.
Or not, sometimes you do just want to be more efficient, and if you don't
want the optimization then disable it some other way. The reason is because
sometimes it is much easier to write the latency multiplying version, and
the conversion to the latency efficient form is trivial for a computer but
extremely easy to screw up for a human being.
EDIT: Hah. I though I recognized Richard's reply. It was to me.