Re: empty-directory predicate, native implementation

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Tue, 13 Oct 2020 04:22:36 +0200
> 
> It is easy to check for an empty dir in elisp; we can just list files
> and check if there is a list or not:
> 
>   (null (directory-files directory-name nil nodots t)))
> 
> where nodots is just regex to omit dot files (from dired+).
> 
> But then this is quite inneficient. We are listing all files in each
> dir since directory-files will return entire content of directory. Also
> we are matching every filename to a regex just to eliminate first two.
> Alternative would be to take length and see if it is > 2; but then we
> would iterate whole list twice. So I can't see anything avialable in
> dired/elisp and I think a predicate implemented in low-level is better 
> solution.
> We are really interested just to see if there is some file; so we can
> just open dir, and read first few entries, if there is more then 2 files
> (. and .. on *nix) we can just abort and return true.
> 
> I have tested an idea with getdents (Linux syscall) and I can see
> difference. Attached is a patch for dired.c and a test file to play with
> some benchmark.

If all we want is to stop reading a directory after N entries, why not
simply extend directory-files to accept one more argument: the maximum
number of file entries to read?  That should be easy to implement, and
will not require us to repeat all the code that is already there in
directory-files (and which you missed).  For example, file names need
to be encoded before they are passed to libc functions (or any
external APIs that expect file names).  As a bonus, we will be able to
return the file names we read, not just ignore them.  And the code
will be much more portable; if someone wants a more efficient
Linux-only version, that could be added as an additional feature
(assuming the speed difference justifies that).

WDYT?