It's probably something inside the kernel (e.g., filesystem code). What does the shell command 'strace -o /tmp/tr -s 128 -T ls -U -1 dirname | wc' say? You can see which system calls are taking the most time by then running 'sort -t"<" -k2n /tmp/tr'. On my platform (Fedora 29 x86-64 ext4, an older desktop with only disk drives), the hoggiest syscalls are getdents64, which are as much as 24 ms per call when the data are not cached, and more like 0.7 ms per call when the data are cached (each such call retrieves about 1000 directory entries). What do you see?
- bug#35531: problem with ls in coreutils Viktors Berstis
- bug#35531: problem with ls in coreutils Kamil Dudka
- bug#35531: problem with ls in coreutils Viktors Berstis
- bug#35531: problem with ls in coreutils Paul Eggert
- bug#35531: problem with ls in coreutils Viktors Berstis
- bug#35531: problem with ls in coreutils Paul Eggert
- bug#35531: problem with ls in coreut... Viktors Berstis
- bug#35531: problem with ls in co... Kamil Dudka
- bug#35531: problem with ls i... Viktors Berstis
- bug#35531: problem with ls i... Kamil Dudka
- bug#35531: problem with ls in co... Paul Eggert
- bug#35531: problem with ls in coreutils L A Walsh
- bug#35531: problem with ls in coreutils Peter Edwards
- bug#35531: problem with ls in coreutils Pádraig Brady