How is this better than the lsd tool?

[StewAlexander-com]

I've used the tool lsd for awhile, what advantages does this have for it?

[PThorpe92]

I think it's really a matter of personal preference. Exa is a few years older than LSD and already had a large user base by the time lsd came around, so I imagine that many use it out of familiarity. Both are awesome tools, I have used both each for quite some time.

This might not be the most helpful answer but I am not sure if there are any significant features we have that lsd does not at this point. If you are curious, maybe try it out for a while and see what you think. 👍

[cafkafk]

As PThorpe said, I think it varies between people. For me personally, one of the biggest reasons can be summed as this:

hyperfine "eza -l --icons" "lsd"
Benchmark 1: eza -l --icons
  Time (mean ± σ):       4.3 ms ±   0.3 ms    [User: 2.6 ms, System: 4.7 ms]
  Range (min … max):     3.9 ms …   5.7 ms    364 runs
 
 
Benchmark 2: lsd
  Time (mean ± σ):     101.4 ms ±   2.5 ms    [User: 4.1 ms, System: 8.6 ms]
  Range (min … max):    97.2 ms … 108.2 ms    29 runs
 
Summary
  eza -l --icons ran
   23.67 ± 1.83 times faster than lsd

However, this is probably better suited to a discussion rather than the issue tracker.

[PurpleMang]

I'm wondering, is this benchmark in some gigantic folder? lsd gets about 14ms in my pictures folder. Maybe it got improved since this post idk

[anorthall]

I've just done several benchmarks on my Mac, and the performance is similar enough that it can be considered totally irrelevant.

On the first run, eza won:

$ hyperfine "eza -l --icons /etc" "lsd -lg /etc" -w 1000 -m 1000
Benchmark 1: eza -l --icons
  Time (mean ± σ):       5.2 ms ±   0.2 ms    [User: 3.4 ms, System: 14.8 ms]
  Range (min … max):     4.7 ms …   7.3 ms    1000 runs

Benchmark 2: lsd -lg
  Time (mean ± σ):       6.4 ms ±   0.4 ms    [User: 2.0 ms, System: 3.1 ms]
  Range (min … max):     5.9 ms …   9.0 ms    1000 runs

Summary
  eza -l --icons ran
    1.24 ± 0.09 times faster than lsd -lg

And on the second, with the same command (but 500 iterations instead of 1,000), lsd won:

$ hyperfine "eza -l --icons /etc" "lsd -lg /etc" -w 500 -m 500 -N
Benchmark 1: eza -l --icons /etc
  Time (mean ± σ):       5.5 ms ±   0.2 ms    [User: 3.5 ms, System: 14.5 ms]
  Range (min … max):     5.1 ms …   7.1 ms    557 runs

Benchmark 2: lsd -lg /etc
  Time (mean ± σ):       3.9 ms ±   0.2 ms    [User: 1.6 ms, System: 0.9 ms]
  Range (min … max):     3.6 ms …   5.8 ms    766 runs

Summary
  lsd -lg /etc ran
    1.40 ± 0.09 times faster than eza -l --icons /etc

And I compared --tree in /etc, where eza was the 'clear' winner, at a whopping 7ms faster!

$ hyperfine "eza --tree /etc" "lsd --tree /etc" -w 250 -m 250 -i
Benchmark 1: eza --tree /etc
  Time (mean ± σ):       3.2 ms ±   0.6 ms    [User: 2.3 ms, System: 1.6 ms]
  Range (min … max):     2.8 ms …  12.1 ms    457 runs

Benchmark 2: lsd --tree /etc
  Time (mean ± σ):       9.0 ms ±   0.3 ms    [User: 1.7 ms, System: 7.0 ms]
  Range (min … max):     8.6 ms …  10.6 ms    250 runs

Summary
  eza --tree /etc ran
    2.79 ± 0.57 times faster than lsd --tree /etc

[zzantares]

someone just needs to clone gh repo clone NixOS/nixpkgs and do the benchmark on that or on the /nix/store of a nix user... 👀

[piechologist]

My pet peeve: eza can sort file names case-sensitively, lsd can't.

[Dini-25]

I like to use the tree view to directories only. I can do this in eza but with lsd i cant as it does not allow to specify the depth of the tree when using the directory only option.

[Picure01]

lsd --tree took 6.28s
eza --tree took 0.29s

it's your choice!

[jtackaberry]

Did you run both with a warm cache? Or did you run lsd first, and then once the cache was warm, eza?

For me, with a warm cache, those commands in my home directory take about the same time. (7 runs each, throwing away the first two and averaged, lsd --tree was 2.198s and eza --tree was 2.233s.)

Edit: of course a couple months has passed, so lsd may have improved since then.

[cafkafk]

I remember observing non-linear runtime issues here, so as the size of the directory grows, the effect would be more pronounced.