Re: empty-directory predicate, native implementation

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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).
Oh; and you say that now when I have just implemented a Windows
version :-).

> WDYT?
I think that sounds like a very good idea; or rather a splended one!
Much better then a predicate. If directory-files is asked just for 1
file, with regex to ignore, it would read max 3 files at most, and on
some filysystems maybe only one file.

> 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).
Actually I didn't; I first tested with ENCODE_FILE but I didn't know
what it does, and it appeared like it is working without, so I ditched
it. I totally forgott about tramp & co, as Michael points out :-).

I didn't count on it to be correct; I am not so very familiar with
Emascs source, there are so many details to take care of, I was rather
just presenting an idea.