5

For a certain directory DIR on my system, the ls --color=always takes about 8 seconds, although it contains less than 10 files and subdirectories. Without the color argument it takes no time.

Why would ls take so long with the color argument, and how can I find out what exactly is taking so long? It is probably some subdirectory in DIR that is mounted, but how can I find out which one is the troublemaker?

3
  • 4
    Have you tried strace?
    – Andrew
    Sep 30, 2011 at 2:23
  • Cool question. +1! Mar 6, 2012 at 19:19
  • strace was so helpful. I had a symlink in the (wrong) dir and when trying to dereference it over NFS it was slowing it down. Sep 10, 2021 at 1:23

4 Answers 4

5

They just disabled color on servers at my work. According to this blog: https://web.archive.org/web/20160410082228/http://www.techper.net/2011/01/25/ls-command-slow-on-very-large-directories/

It may be due to the stat() function being called on all the different mounts in a specific directory to get the information presented by the colors...

It's easy to confirm this:

time command ls /dir/with/many/toplevel/entries/ >/dev/null
time $SHELL -c "ls --color=always /dir/with/many/toplevel/entries/ >/dev/null"

The first command, for a certain problematic directory structure I created, gives:

real    0m0.523s
user    0m0.284s
sys     0m0.052s

And the second one:

real    1m47.799s
user    0m0.360s
sys     0m0.928s

Please keep in mind that if you repeat the bottom "benchmark", its second run will have the stat() data already in cache. The second run for the colorized output gave me:

real    0m0.409s
user    0m0.256s
sys     0m0.120s

I was unable to completely clear the cache to ensure I could reproduce the "more than 90secs" result. The vm.drop_caches sysctl as described in https://stackoverflow.com/questions/599719/how-to-clean-caches-used-by-the-linux-kernel was insufficient.

1
  • 10 stat() calls does not take 8 seconds.
    – joshudson
    Mar 13, 2017 at 18:43
1

Try doing ls using *s to only list certain things and see which combinations are slow.

0

Some color configurations are silly and read file contents. Check your config. I use colorized ls but only such that lstat would provide all the required information.

0

Based on the comments in this bug report, one solution/workaround (which I can confirm works for me) is to add the following to your ~/.profile file:

eval `dircolors -b | sed s/or=[^:]*://`

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .