В Linux с некоторыми файловыми системами тип файла (обычный, устройство char, блочное устройство, каталог, канал, ссылка sym, ...) хранится в структуре linux_dirent, в которую ядро передает записи каталога приложений через системный вызов getdents. Если единственной вещью в структуре статистики, в которой вы нуждались, был тип файла, и вам нужно было получить его для всех или многих записей каталога, вы можете использовать getdents напрямую (а не readdir) и попытаться получить тип файла из этого, только используя stat, если вы нашли неверный тип файла в linux_dirent. В зависимости от модели использования файловой системы вашего приложения это может быть быстрее, чем использование stat, если вы используете Linux, но во многих случаях stat должен быть быстрым.
Скорость Stat в основном связана с поиском запрашиваемых данных на диске. Если вы просматриваете каталог с рекурсивной статистикой всех файлов, то каждая статистика должна в целом быть довольно быстрой, потому что большая часть работы по получению данных статистики заканчивается кэшированием перед тем, как вы запросите ядро для этого при предыдущем вызове stat , С другой стороны, если вы регистрируете одинаковое количество файлов, случайно распределенных по системе, ядру, вероятно, придется считывать с диска несколько каталогов для каждого файла, для которого вы собираетесь вызывать stat.
fstat всегда должен быть очень быстрым, поскольку ядро уже должно иметь данные, которые вы запрашиваете в оперативной памяти, так как ему необходим доступ к нему, чтобы файл находился в открытом состоянии, и ядру не нужно было идти из-за проблем с обходом пути к имени файла, чтобы увидеть, находится ли каждый компонент в оперативной памяти или на диске, и, возможно, для чтения в каталоге с диска (но, вероятно, не нужно), только чтобы обнаружить, что он содержит данные, которые вы запрашиваете в оперативной памяти.
При этом вызов stat для открытого файла должен быть быстрее, чем вызов для неоткрытого файла.