That is not at all the behavior that I am observing on my system:

"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.

The stat() results are going to be cached.

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...

Okay, updated results (cleared all the caches and restarted shell/terminal between runs):

"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.

The fair test is the hardware you’re going to be running it on

I'd say this is a situation where you should use a tool that's appropriate for the job.

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.

I'm not sure I'm following. Listing 70k files was a benchmark. It would take you 10x the time to use 'exa | grep' but grep might just filter out the item you're looking for during execution (not certain if grep is reading the pipe as it is output or waits for execution to complete first). exa still needs 7 seconds to check all files. ls only needed a tenth of that

The point is that exa is a tool for listing files in a more human readable way. In what situation would you ever need to manually read (with your eyes) a list of 70k files? For this use case you should just use ls.

I'm saying you would use `ls | grep ...` in situations where you're transforming the output but use `exa` when you specifically care about the files or their metadata.

That is, use ls when you you don't care about the direct output of the list file command, use exa when you do.

I agree with your point but most things you might want "ls|grep" for is better done with "find" which can do both in one.

Or indeed ‘fd’, which is a find replacement with nicer search syntax.

Sure. Use what you know and what you're comfortable with.

> (not certain if grep is reading the pipe as it is output or waits for execution to complete first)

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.

Wow. This is very slow. If the only feature here is that it supports colors (so does ls, by the way) or extra information (so does ls, by the way), all while being much slower, then I do not see the point in replacing ls with this.

Someone mentioned that you can just do:

  alias ll='ls -lahF --color=auto'

exa does (or can do) more than that. Git information, for example; and more fine-grained output control.

Does the slowness really matter for most use cases though?

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.

>Yes, it matters a lot.

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.

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 don't think anyone would use a tool if it were 180x slower than the alternative. I strongly doubt that's the case here.

(to clarify the "180x" math: (10s - 1s) / (250ms - 200ms) = 9s / 50ms = 180)

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've been using exa for the better part of a decade and never noticed any delay whatsoever.

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.

>Helper scripts using ls can involve lots of items and recursion, so the slowness can go exponential.

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.

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.

Even the most strident fans of exa wouldn't advocate replacing ls with exa. We just set it as an alias which won't affect script execution.

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.

ls is probably one of the most used command line utilities, up there with `cd` and `echo`. It will be very easy to notice performance degradation.

I find comments like "I've been using <the tool> forever and never noticed <this> problem" a little annoying. But, I fall into this camp here. I'm not trying to dismiss other people's criticism that the slowness has had a negative effect on their workflow. But, here it goes, I use exa as my ls replacement and I've never even noticed it was slow. And, for me, the chief value really comes down to exa's color coding of results. It helps me see the information more easily which I feel has a cumulative effect of speeding up my workflow.

That does seem rather bad, I wonder what is causing such shitty performance?

From the documentation

> 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.

But you have to run stat to get the details, like permissions, dates and size, whether your name is "exa" or "ls".

I'm willing to bet it's the fact that they're in a git repo. exa checks git status iirc, and of course ls doesn't. I'll try to repro it.

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

Yeah at first I thought maybe the git feature but in the demo they're not passing --git. See also: https://github.com/ogham/exa/issues/367#issuecomment-4285909...

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.

Based on perf report, the latest stable version of exa is spending >99% of its time doing grid stuff. I pulled the repo from git, and using the latest master commit, it appears to have a huristic to not bother with the grid when you have lots of files. Now the times are a lot closer. (redirected stdout to /dev/null since otherwise the vast majority of the time would simply be outputting to the shell)

    [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

Exa does colors and other stuff by default. I would wager it’s stat()ing every file and ls isn’t.

>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.

Make it work, make it correct, make it fast - perhaps they haven't reached phase three yet?

Then they shouldn't market it as being fast.

There seem to be an issue reported about this (although when passing -l): https://github.com/ogham/exa/issues/141

I once experimented with a design that ended up with 30,000 files in a single directory. (It was a dumb experiment.)

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.

For a counter anecdote, I've been using it for years on a few systems and never had any speed issues at all.

A lot of people will time things down to the microsecond and complain about a 0.1% difference and proclaim "this tool is garbage". I expect that sort of thing on reddit but not on HN.

the --tree feature is incredibly slow

Comparing tree to exa --tree, they're not that different in total runtime, it's just that exa doesn't print till it's done while tree prints as it goes and it feels so much worse (to use exa)