exa: Exa is terribly slow with '-l' (long) mode on specific environment

Exa 0.4.0 on Linux x86-64 (Ubuntu 14.04)

$ exa --version
exa 0.4.0
$ uname -a
Linux XXXXXXXX 3.16.0-60-generic #80~14.04.1-Ubuntu SMP Wed Jan 20 13:37:48 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

exa -l is terribly slow on this environment.

~/.dotfiles$ time exa | wc -l
17

real    0m0.076s
user    0m0.001s
sys     0m0.076s

~/.dotfiles$ time exa -l | wc -l
17

real    0m1.788s
user    0m0.005s
sys     0m1.841s

~/.dotfiles$ time command ls -l  | wc -l
18

real    0m0.004s
user    0m0.002s
sys     0m0.004s

It can be reproduced both on git repository and on non-git repository. I suspect that when it is a long mode, exa is trying to access to some metadata of files but the access is very slow (but I do not know which one is the culprit).

I do not experience the performance degradation on my laptop, macOS 10.11.6. In addition, on another linux system that I have an access (Linux 4.8.6-x86_64, Ubuntu 16.04) the issue is not happening (exa -alh is very fast). Looks like that this issue is environment-specific.

About this issue

Original URL
State: open
Created 7 years ago
Comments: 18 (6 by maintainers)

Commits related to this issue

Only get an Env if one’s being used, also mutexes This commit ties a table’s Environment to the fact that it contains columns. Previously, the Details view would get its Environment, and then use th... — committed to ogham/exa by ogham 7 years ago

Most upvoted comments

I can confirm that the issue remains in 0.9.0, and also on MacOS (10.14.6) with only 4 cores.

My test directory has only 32 files. The command is simply my default alias (artificial line breaks) …

exa --color auto 
    --all --group-directories-first 
    --long 
    --binary 
    --group 
    --header 
    --modified  
    --sort=name  
    --git  
    --time-style=long-iso  
    --classify

It took 7.5s to run, even after multiple consecutive runs. (Note the time command in the screenshot seems to truncate the full command that was run)

Screen Shot 2019-08-27 at 10 29 29 AM

Adding the -G option drops the time to 0.02s, but also drops other flags, like the headers and git info, etc.

Running dtruss (Mac’s strace), it’s clear that the major offender is psynch_mutexwait calls.

2019-08-27 EXA dtruss output.txt

Hopefully one more data point helps a bit.

skoskie on Aug 27, 2019

I may have solved this in #510, it would be nice to know if my PR fixes the complaints here.

I’ve added a threadpool for making lstat and stat syscalls which can be very slow in the environment where I use exa; by default my PR launches one thread per CPU but the number of threads can be controlled manually by setting EXA_IO_THREADS.

saethlin on Jun 17, 2019

Another something weird: If we use -G option along with -l, exa gets very fast.

wookayin on Jan 2, 2017