[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dired and ls (was: Human-readable file sorting)
From: |
Eli Zaretskii |
Subject: |
Re: dired and ls (was: Human-readable file sorting) |
Date: |
Sat, 20 Feb 2016 11:57:40 +0200 |
> From: Lars Ingebrigtsen <address@hidden>
> 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.
- Re: Human-readable file sorting, (continued)
- Re: Human-readable file sorting, Michael Heerdegen, 2016/02/20
- RE: Human-readable file sorting, Drew Adams, 2016/02/20
- dired and ls (was: Human-readable file sorting), Lars Ingebrigtsen, 2016/02/20
- Re: dired and ls, John Wiegley, 2016/02/20
- Re: dired and ls, Lars Ingebrigtsen, 2016/02/20
- Re: dired and ls, John Wiegley, 2016/02/20
- Re: dired and ls, Thierry Volpiatto, 2016/02/23
- Re: dired and ls, John Wiegley, 2016/02/23
- Re: dired and ls (was: Human-readable file sorting),
Eli Zaretskii <=
- Re: dired and ls, John Wiegley, 2016/02/20
- Re: dired and ls, Eli Zaretskii, 2016/02/20
- Re: dired and ls, John Wiegley, 2016/02/20
- Re: dired and ls, Lars Ingebrigtsen, 2016/02/20
- Re: Human-readable file sorting, Eli Zaretskii, 2016/02/20
- Re: Human-readable file sorting, Lars Ingebrigtsen, 2016/02/20
- Re: Human-readable file sorting, Eli Zaretskii, 2016/02/20
- Re: Human-readable file sorting, Lars Ingebrigtsen, 2016/02/20
- Re: Human-readable file sorting, Eli Zaretskii, 2016/02/20
- Re: Human-readable file sorting, Lars Ingebrigtsen, 2016/02/20