对于我系统中的某个目录DIR， ls --color=always需要大约8秒，尽pipe它包含less于10个文件和子目录。 如果没有颜色参数，它不会花时间。
为什么我会花这么长时间的颜色论证，我怎么才能找出究竟花了这么久？ 这可能是DIR中的一个子目录，但是我怎么知道哪个是麻烦制造者呢？
他们只是在我的工作中禁用服务器上的颜色。 根据这个博客： 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"
第一个命令，对于我创build的某个有问题的目录结构，给出：
real 0m0.523s user 0m0.284s sys 0m0.052s
第二个：
real 1m47.799s user 0m0.360s sys 0m0.928s
请记住，如果您重复底部“基准testing”，则第二次运行的数据已经存在于caching中。 第二次彩色输出给了我：
real 0m0.409s user 0m0.256s sys 0m0.120s
我无法完全清除caching，以确保能够重现“超过90秒”的结果。 如https://stackoverflow.com/questions/599719/how-to-clean-caches-used-by-the-linux-kernel中所述的vm.drop_caches sysctl不足。
试着用* s来做ls只列出某些东西，看看哪些组合是慢的。
一些颜色configuration是愚蠢的，阅读文件的内容 。 检查你的configuration。 我使用彩色ls，但只有这样，lstat才能提供所有必需的信息。