Re: dired and ls (was: Human-readable file sorting)

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 20 Feb 2016 17:16:09 +1100
> 
> This all reminds me of something I forgot to prattle on about in that
> dired bug report: ls-lisp.el.
> 
> dired (on Unixey systems) uses "ls" to get the contents of directories,
> and then parses the results.  And generates a buffer.  Not all systems
> have "ls", so in that case it uses ls-lisp.el, which just calls
> directory-files and then file-attributes in a loop.
> 
> I think this is rather suboptimal for many reasons:
> 
> 1) dired look unnecessarily different on different systems
> 
> 2) the customisability is limited -- both the look of the buffers and
> the sorting is limited by what the native "ls" returns
> 
> 3) Reasons!  So many reasons!
> 
> I've asked "but why" before, but the only response I can remember is "ls
> is faster".

There's another reason: ls-lisp implements only a subset of options
supported by 'ls' the program.

> Which may be true!  (I may be misremembering this being the
> only answer.)  Because `directory-files' uses opendir/readdir first to
> get the file names, and then we have to stat each and every file just to
> find out whether they're files or directories.
> 
> If we instead had `directory-files-with-attributes' in C, we could just
> do what "ls" does, which is...  opening the directory, reading it, and
> then statting all the files.

ls-lisp already uses directory-files-with-attributes.

> So it should be just as fast?  I think?

You should measure it, instead of trying to reason about that.  IME,
reasoning about relative timings of programs is never a good idea,
because measurements always produce surprising results.

One reason why ls-lisp might be slower is that it performs quite a bit
of processing after reading the directory, and that processing is
faster in C than in Lisp.  But it could be faster in insignificant
ways.