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):
41 Likes
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. 
So fast it doesn’t even need emojis!
1 Like
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.
