8 ms·

I used to think exa was a good ls replacement, but I found out that it's significantly slower than ls[0]. Heck, it's even slower than lf[1]. Quite frankly I did

• authed 5y ago
  the --tree feature is incredibly slow
  • 3836293648 5y ago
    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)
• mikkelam 5y ago
  That does seem rather bad, I wonder what is causing such shitty performance?
  • kreetx 5y ago
    Make it work, make it correct, make it fast - perhaps they haven't reached phase three yet?
    • Narishma 5y ago
      Then they shouldn't market it as being fast.
  • xxpor 5y ago
    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
    • esprehn 5y ago
      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-428590907 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.
      • lilyball 5y ago
        Exa does colors and other stuff by default. I would wager it’s stat()ing every file and ls isn’t.
      • xxpor 5y ago
        >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.
      • xxpor 5y ago
        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
  • miohtama 5y ago
    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.
    • kazinator 5y ago
      But you have to run stat to get the details, like permissions, dates and size, whether your name is "exa" or "ls".
      • deleted 5y ago
        [deleted]
• johnisgood 5y ago
  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'
  • netizen-936824 5y ago
    Does the slowness really matter for most use cases though?
    • stjohnswarts 5y ago
      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.
    • johnisgood 5y ago
      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.
      • netizen-936824 5y ago
        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
        • newjersey 5y ago
          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.
• tills13 5y ago
  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.
  • smokey_circles 5y ago
    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
    • tills13 5y ago
      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.
      • vidarh 5y ago
        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.
        • nicoburns 5y ago
          Or indeed ‘fd’, which is a find replacement with nicer search syntax.
        • tills13 5y ago
          Sure. Use what you know and what you're comfortable with.
    • this_machine 5y ago
• elliotlarson 5y ago
  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.
• bool3max 5y ago
  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.
  • chasil 5y ago
    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-pagecache-disk-cache-under-linux/ https://www.thegeekdiary.com/how-to-clear-the-buffer-pagecac...
    • sincerely 5y ago
      The fair test is the hardware you’re going to be running it on
    • bool3max 5y ago
      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.
• Zitrax 5y ago
  There seem to be an issue reported about this (although when passing -l): https://github.com/ogham/exa/issues/141 https://github.com/ogham/exa/issues/141
• ddoolin 5y ago
  For a counter anecdote, I've been using it for years on a few systems and never had any speed issues at all.
  • stjohnswarts 5y ago
    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.
• deleted 5y ago
  [deleted]
• watersb 5y ago
  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.