1.1M files -> 120 seconds
1.8M files -> 270 seconds (this could be related to system load being over 90 heh)
Which filesystem you use will also make a big difference here. You could imagine some filesystem that uses the getdirentries(2) binary format for dirents, and that could literally memcpy cached directory pages for a syscall. In FreeBSD, UFS gets somewhat close, but 'struct direct' differs from the ABI 'struct dirent'. And the FS attempts to validate the disk format, too.
FWIW, FreeBSD uses 4kB (x86 system page size) where glibc uses 32kB in this article[1]. To the extent libc is actually the problem (I'm not confident of that yet based on the article), this will be worse than glibc's larger buffer.
[1]: https://github.com/freebsd/freebsd-src/blob/main/lib/libc/ge...
2.25M and its 60 seconds
I'm also spamming about 16-18 thousand new files per second to disk using a very inefficient set of csh scripts...
seq 1 8000000 | xargs touchStrangely "jot -w file 8000000 1 | xargs touch" worked.
I'm going to try to replicate this because I sense some kind of tomfoolery.
"ls" is using 2.5GB of ram, 76 seconds.
"ls -f" is using 2.4GB of ram, 18 seconds.
"ls -mf" uses like 2.4GB of ram, 20 seconds.
For those who say "cache!", no, I pre-warmed the cache and this is the result after that.
There are a few other things that could be related since the original article was about a VM. The VM is going to be affected by SPECTRE/Meltdown patches, a known performance thief. I've got them enabled on this box but I'll disable them shortly and re-test. Also my test box has 64GB of ram and is running FreeBSD 13 with ZFS. I get about 150MB/sec and 1100IOPs with the spinning rust drives.
Update: Turned off Spectre/Meltdown patches, "ls -f" takes 17 seconds, "ls -mf" takes 18 seconds, "ls" takes 70 seconds.