Почему мог бы 'ls - color=always' быть медленным для маленького каталога?

Попробуйте выполнить ls, используя * s, чтобы перечислить только определенные элементы и посмотреть, какие комбинации медленные.

Они просто отключили цвет на серверах на моей работе. Согласно этому блогу: http://www.techper.net/2011/01/25/ls-command-slow-on-very-large-directories/

Это может быть связано с тем, что функция stat () вызывается на всех различные монтирования в определенном каталоге для получения информации, представленной цветами ...

Это легко подтвердить:

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

Первая команда для определенной проблемной структуры каталогов, которую я создал, дает:

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

И второй:

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

Имейте в виду, что если вы повторите нижний «тест», его второй прогон будет иметь данные stat () уже в кеше. Второй прогон цветного вывода дал мне:

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

Мне не удалось полностью очистить кеш, чтобы гарантировать, что я смогу воспроизвести результат «более 90 секунд». Sysctl vm.drop_caches , как описано в https: // stackoverflow.

Некоторые цветовые конфигурации выглядят глупо и читают содержимое файла . Проверьте свою конфигурацию. Я использую раскрашенные ls, но только так, чтобы lstat предоставлял всю необходимую информацию.

Основываясь на комментариях в этом отчете об ошибке, одно решение/обходной путь (который, я могу подтвердить, работает для меня) состоит в том, чтобы добавить следующее в ваш ~/ Файл .profile:

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