←back to thread

lsr: ls with io_uring

(rockorager.dev)
335 points mpweiher | 1 comments | | HN request time: 0.203s | source
Show context
tln ◴[] No.44605002[source]
The times seem sublinear, 10k files is less than 10x 1k files.

I remember getting in to a situation during the ext2 and spinning rust days where production directories had 500k files. ls processes were slow enough to overload everything. ls -F saved me there.

And filesystems got a lot better at lots of files. What filesystem was used here?

It's interesting how well busybox fares, it's written for size not speed iirc?

replies(2): >>44605833 #>>44605879 #
SkiFire13 ◴[] No.44605833[source]
> The times seem sublinear, 10k files is less than 10x 1k files

Two points are not enough to say it's sublinear. It might very well be some constant factor that becomes less and less important the bigger the linear factor becomes.

Or in other words 10000n+C < 10000(n+C)

replies(1): >>44607490 #
1. tln ◴[] No.44607490[source]
The article has data points for n=10,100,1000,10000. Taking (n=10,000 - n=10)/(n=1,000 - n=10) would eliminate the constant factor and we'd expect about 10.09x higher times for a linear algorithm.

But for lsr, it's 9.34. The other tools have factors close to 10.09 or higher. Since ls has to sort it's output (unless -F is specified) I'd not be too surprised with a little superlinearity.

https://docs.google.com/spreadsheets/d/1EAYua3B3UeTGBtAejPw2...