On 11/11/22 05:13, kdevel wrote:
> dmd -O compiled patched (see below!) version applied to /usr/bin on my
> ftw : 363 ms, 750 ÎŒs, and 5 [*]
> dirEntries: 18 secs, 831 ms, 738 ÎŒs, and 3 [*]
Great. I did not use -O with my test. It may have to do something with
the performance of the hard disk.
ftw wins big time. Being just a D binding of a C library function, its
compilation should be quick too.
>> entries ~= DirectoryEntry(entry, entry.getSize);
> strace reports that entry.getSize invokes stat on the file a second
> time. Isn't
> the stat buf saved in the entry?
That's my bad. entry.size is the cached version of the file size.
> This also gives rise for a complication with symlinks pointing to the
> which contain them:
> $ pwd
> $ ln -s . foo
> $ ../direntrybenchmark .
Too many levels of symbolic links
So, ftw does not have that problem? Perhaps because of its default
symlink behavior? There is also the more capable nftw, where the caller
can specify some flags. And yes, there it is:
If set, do not follow symbolic links. (This is what you want.)
If not set, symbolic links are followed, but no file is reported
If FTW_PHYS is not set, but FTW_DEPTH is set, then the function
fn() is never called for a directory that would be a descendant
> - const dir = buildNormalizedPath("/home/ali/dlang");
> + const dir = buildNormalizedPath(args);
That one, and I had switched the arguments on the following call. One
more example where string interpolation would be useful:
writefln!"Ignoring type %s file: %s\n(See 'man nftw')b"(
I meant the arguments in the reverse order there.
OT: And there is a 'b' character at the end of that format string which
almost certainly appeared when I botched a Ctrl-b command in my editor. :)