-
-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: eza
is substantially slower than ls
in large directories
#922
Comments
In this comment lsd-rs/lsd#378 (comment) I did some benchmarking that compared the performance of I'll update it to use |
I created a directory in /tmp with 50,000 empty files. On my Linux system, /tmp is a tmpfs, and
Then I compared the execution time of The options were intended to disable features that differ between programs (such as icons and colors) but still display single line or long" output. Single line output ("-1")
Long output ("-l")
Next I logged the system calls made by each program.
You can see that lsd had many more system calls than the others. It's strace output was about 883M, so keep that in mind if you test on a directory with more files. Here's a count of how many times each system call was made for each program.
I used a spreadsheet to put the strace results in a table for easier comparison.
The only one that stands out to me for |
Yeah I'm curious about that as well. Writing to stdout perhaps (i.e. no buffering)? we'd be really grateful if you have time to figure out where that's coming from (especially if it significantly affects the runtime). I think @tertsdiepraam was looking into this as well a while ago. |
This is what I was looking into: #833
Stdout is already line buffered so I don't think writing will be super expensive, but could still be optimized of course. |
The system call results are from using the long output ( |
Ah that explains my confusion, because uutils should do way fewer statx calls with |
Here are the results from running with the single line (
Here's a count of how many times each system call was made for each program.
Notice the |
You should consider adding an option that limits the number of lines printed, maybe |
Not a bad idea, even as just a nice feature to replace |
Also, it might not be necessary for the case when classify and icons are turned off. |
Indeed, that's what my PR does. It puts the metadata behind a |
I noticed a substantial slowdown as well. Example (single sample):
It seems like the futex / clone3 syscalls take the longest. |
As discussed here,
eza
is significantly slower thanls
when listing files in large directories. This issue persists with the latest version (0.18.9).Here's a benchmark for a directory with ~50k files:
The text was updated successfully, but these errors were encountered: