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

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 18051 <at> debbugs.gnu.org
Subject: bug#18051: 24.3.92; ls-lisp: Sorting; make ls-lisp-string-lessp a normal function?
Date: Fri, 18 Jul 2014 12:12:48 +0200

Eli Zaretskii <eliz <at> 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.

Previous Next

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