4 ms·

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

by mikkelam 5y ago

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]

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]