Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a draft because I made this PR more to spark some conversation than to actually change the code. It could still be merged if I clean it up but (spoiler alert) the improvement is very small for now. So here goes.
eza
is super fancy, but sometimes quite slow. As seen in some issues and discussions:(and probably some more, I've only started tracking this recently)
This is not necessarily a problem: as I understand it,
eza
is meant for fancy output first and fast output second. It fulfills the promise of being fancy very well and that fanciness sets it apart from e.g. GNU (and uutils)ls
. Still, the fact that complains are coming in shows that people would likeeza
to be faster.Now, I've done a bunch of work on uutils
ls
, including performance work, so I figured I'd share some of my experience. In my experience, it's quite hard to getls
-like programs to a low number of syscalls. If you want to try this for yourself, compare these commands (on Linux):Here's the top of both, first
eza
:and then GNU
ls
:You can see that
eza
spends a lot of time on syscalls that's probably not necessary!So, I set out to see if I could reduce that with a similar technique as we used in uutils
ls
: retrieving metadata and filetype only when necessary. In code, it's similar to how the extended attributes and canonicalized name are computed with aOnceLock
. Now there are two options:DirEntry
, which already contains aFileType
, so if we have that, we can often skip getting the metadata.So I implemented that and the number of statx calls from running
eza
on its own repository went from 33 to... 23. Not quite what I had hoped. Turns out that's because on every regular file,eza
wants to know whether the file is executable, which requires the full metadata. Removing that check drops the statx calls to 0, which I think would lead to a measurable speedup, but I've left that out of this PR, because that would changeeza
's behaviour.This all raises some interesting questions (which are probably worth spinning off into an issue):
readlink
/getcwd
calls for? They take up a lot of time and are probably unnecessary.eza
even more with--color=never
.Hope this all makes sense :)