Yes, it matters a lot. These tools are supposed to be fast. I use them all the time, and if there is a tool that does the same but one takes 1 sec and the other one takes 30 seconds, then of course I am going to pick the faster one.
And they are. Just not faster than ls, which is already fast itself.
>I use them all the time, and if there is a tool that does the same but one takes 1 sec and the other one takes 30 seconds, then of course I am going to pick the faster one.
Only if it matters.
If it takes 200ms and the other 250ms nobody's going to care. Especially if the second tool does more, and especially if the use case is "listing of regular dirs where better human-readability matters" (not 20K+ file dirs).
The same way we also program Python or JS or Lisp and not just C and Rust, even though the latter are faster.
Yes, it matters to me because I use it often, and many directories have lots of files in them.
I do not care if the difference is 200 ms vs 250 ms, but if it is 1 sec vs 10 seconds, then yeah, it is a deal-breaker.
I did not try exa, so I cannot speak against it, nor in favor of it. It would only be fair if I used it and noticed that there are significant performance issues with it.
I only took a quick glance at the OP's https://asciinema.org stuff. Exa seemed way slower in comparison to ls. Again, I would have to test it myself and see how much it affects me if at all. That said, I do not see a reason to switch to it because ls supports colors as well, and I do not need the added extra information. Welp.
I do as well, but I guess none of my use cases have involved either listing absurd amounts of files nor have I used ls or exa in any scripts. I do use exa and ls (usually on systems where I don't have exa installed or when I forget to type "sl" instead)
The difference has been barely noticeable for me
From what I have read here, it diesnt look loke anyone dislikes exa. The only thing I'd change is the messaging.
Instead of saying modern replacement to ls, I'd rather we be more specific and say "a modern replacement to ls for some interactive workloads" or something like that. This makes it clear that the ask is not that we remove the ls binary and put exa alias.
I suppose it depends on a person and situation. Significant amount of my lists end up an overfull directory of logs or traces or whatevers. Basic utilities used daily (hourly? Minutely?) need every inch of speed eeked out.
Many of the interactive tools you use are bash scripts so I seriously doubt that the above benchmark is meaningful for normal use cases. Whether you see that 4 files in 0.01 or 0.05s is basically the exact same and this wait time doesn’t accumulate.
Helper scripts using ls can involve lots of items and recursion, so the slowness can go exponential. A serious replacement candidate needs to be as fast or faster.
Maybe a performance based execution of exa could be crafted that ignores some of the eye candy or whatever is sucking up the cycles.
Scripts using ls should keep using ls whatever you use for interactive use. Though more often than not such scripts ought to use something else like find to begin with.
No it doesn't but you will get people who like to nitpick speed and forget about all the other advantages that other users find useful and appreciate them. Most people will never notice the speed difference.
