0: https://asciinema.org/a/454216 vs https://asciinema.org/a/454217
"time command ls -lR -color=always": 898 millis
"time command exa -lhgR --icons": 638 millis
This is in a directory of roughly 17k files of varying filetypes. Exa also outputs underlines and icons.
---
Admittedly if I create 80000 arbitrary extensionless files "ls" takes around 700 millis while exa takes around 1000 millis, but still the performance difference is nowhere near what you demonstrated.
I don't know what job you're doing that requires "ls"-ing >20k files, but on my system there seems to be no performance penalty before an uncertain, unachievable threshold.
What is fair for a test like this? SSD or rotational media?
At least clear the caches between runs, or give them the same cache.
https://www.thegeekdiary.com/how-to-clear-the-buffer-pagecac...
"time command ls -lR --color=always": 12.31 secs
"time command exa -lgR --icons": 11.32 secs
Still, no performance difference on my system. In fact exa seems to be slightly faster (I did the test multiple times and it was alwasy ~1 second faster). This is on a physical HDD and I could hear it churning equivalently on both of the runs.
Listing 70k files without greping or piping into another process is something you are probably not going to ever do. exa seems very good for the average case.
That is, use ls when you you don't care about the direct output of the list file command, use exa when you do.
Commands to the left of the pipe block upon writing to the pipe, and commands to the right of the pipe block upon reading. As something is written to the pipe, it gets read by the next process in the pipeline.
Data flows through Unix pipelines as it is written, and data flow is not dependent on completed execution.
Someone mentioned that you can just do:
alias ll='ls -lahF --color=auto'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.
No, not at all.
>These tools are supposed to be fast.
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.
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.
(to clarify the "180x" math: (10s - 1s) / (250ms - 200ms) = 9s / 50ms = 180)
Maybe a performance based execution of exa could be crafted that ignores some of the eye candy or whatever is sucking up the cycles.
It can't go exponential. Recursion or not, you did N passes with ls, and you'll do N passes with exa.
Unless exa is exponentially (not by a linear factor) slower than ls, the slowness can't go exponential.
Edit:
Hmm, interesting. Certainly a lot slower, but not enough that I'd really notice unless I was doing this constantly:
time ls
real 0m0.228s
user 0m0.145s
sys 0m0.082s
time exa
real 0m1.209s
user 0m1.124s
sys 0m0.084s
ls taking seconds and exa taking 13 minutes :(
Their website says it's as fast as ls because they do things in parallel but it doesn't seem to actually be as fast as ls in small or large usage.
I'd also say 200ms -> 1.2 seconds is very noticable.
One of those things that if I'm looking for it, I'd notice but otherwise...
I deal with so many slow CLI tools daily that it wouldn't even register.
[user@anarchy:~/exa_test]$ time ../exa/target/release/exa >/dev/null
../exa/target/release/exa > /dev/null 0.05s user 0.07s system 99% cpu 0.122 total
[user@anarchy:~/exa_test]$ time /bin/ls >/dev/null
/bin/ls > /dev/null 0.03s user 0.01s system 99% cpu 0.048 total> Here’s an example. exa, by default, runs the stat system call on every file it encounters. This requires communicating with the storage device or hard disk to get that file’s type and permissions, which determine how that file gets coloured and displayed on screen. The system call, which may have been expensive in the days of time-shared computers and slow connections, is still not free, but is extremely cheap. The extra information is worth the minuscule increase in processing time.
For 100% - ~3 use cases the performance difference does nit matter as a human is unable to react in milliseconds. You can always fallback to ls.
I discovered that the ls I as using used a polynomial-time algorithm for sorting the output. Like, it would lock up the machine for ten minutes... Told ls not to sort, and boom... fast.
This was almost 20 years ago. And I don't recall if it was GNU ls or FreeBSD.
There may be some performance improvement opportunities out there for exa.