bug#18051: 24.3.92; ls-lisp: Sorting; make ls-lisp-string-lessp a normal function?

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

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Tramp uses ls-lisp only in case it cannot use a native method on the
>> remote host. Experience shows, that ls-lisp has a much worse performance
>> for remote directories than native implementations.
>
> Any insight as to why this happens?  Perhaps the Tramp implementation
> of directory-files-and-attributes needs some love?

Maybe it is a misunderstanding. Tramp's native implementation is much
faster, because it sends exactly one remote command. For ssh-like
connections, this is for example

# echo "("; (/bin/ls --color=never -a | sed -e s/\$/\"/g -e s/^/\"/g | xargs \stat -c '("%n" ("%N") %h %ue0 %ge0 %Xe0 %Ye0 %Ze0 %se0 "%A" t %ie0 -1)' 2>/dev/null); echo ")" 2>/dev/null

This is much faster than ls-lisp, which must determine file-attributes
for every single file in a remote directory (which is a remote command
on its own).

>> I would oppose to make ls-lisp the default, and to add functionality to
>> it which would not be available otherwise.
>
> If this is because of Tramp, nothing prevents us from using 'ls' on
> the remote host, and then manipulate the results locally in Lisp,
> right?  So I'm not sure I understand the rationale for your
> objections.  Perhaps revealing more details will help.

I would oppose only if there is an additional mandatory functionality in
ls-lisp other file name primitives are urged to use. If there would
be changes in, let's say, directory-files-and-attributes, there's no
problem for me. But that's not what Michael has asked for.

Best regards, Michael.