I applied some of my io_uring learnings to writing an implementation of ls(1) with the goal of minimizing syscalls. The repo is here, and I did a little writeup here. I was mostly interested in the syscall reduction I could get in a realistic program which relies very little on traditional IO (reads, writes, etc). Nearly all the IO for something like ls are syscalls: statx to be specific. I benchmarked syscalls and time of several popular options, syscall results are below.
| Program | n=10 | n=100 | n=1,000 | n=10,000 |
|---|---|---|---|---|
| lsr -al | 20 | 28 | 105 | 848 |
| ls -al | 405 | 675 | 3,377 | 30,396 |
| eza -al | 319 | 411 | 1,320 | 10,364 |
| lsd -al | 508 | 1,408 | 10,423 | 100,512 |
| uutils ls -al | 445 | 986 | 6,397 | 10,005 |
and here’s a bonus screenshot! I added some fancy icons to be like the other big guys (eza and lsd):
Nice! Curious, did you happen to measure latency differences?
Ah, I see it’s in the write-up. I think you can put the latency table here too, because in the end, that’s all that matters (as long as the ouput is correct) for ls. 
Here’s the table!
| Program | n=10 | n=100 | n=1,000 | n=10,000 |
|---|---|---|---|---|
| lsr -al | 372.6 µs | 634.3 µs | 2.7 ms | 22.1 ms |
| ls -al | 1.4 ms | 1.7 ms | 4.7 ms | 38.0 ms |
| eza -al | 2.9 ms | 3.3 ms | 6.6 ms | 40.2 ms |
| lsd -al | 2.1 ms | 3.5 ms | 17.0 ms | 153.4 ms |
| uutils ls -al | 2.9 ms | 3.6 ms | 11.3 ms | 89.6 ms |
So fast it doesn’t even need emojis!
Really cool, with alias my new ‘l’, ‘ll’. 
I’ve been running into an intermittent issue. Occasionally I will get an error: SystemResources when I run it. Eventually it corrects, but if I get it in one shell session, then that session is always returning that error.
What kernel version do you have?
$ uname -srm
Linux 6.14.5-300.fc42.x86_64 x86_64
Default kernel for Fedora 42
Looks like it might be due to memory pressure (reported as 90% memory usage)? I killed a few processes and it’s working again.