Почему `найти. -типа f` займет больше времени, чем `find .`?

Кажется, findчто в любом случае придется проверить, соответствует ли данный путь файлу или каталогу, чтобы рекурсивно просмотреть содержимое каталогов.

Вот некоторая мотивация и то, что я сделал на местном уровне, чтобы убедить себя, что на find . -type fсамом деле медленнее, чем find .. Я еще не копался в GNU найти исходный код.

Поэтому я создаю резервные копии некоторых файлов в моем $HOME/Workspaceкаталоге и исключаю файлы, которые являются либо зависимостями моих проектов, либо файлами контроля версий.

Итак, я запустил следующую команду, которая выполнялась быстро

% find Workspace/ | grep -v '/vendor\|/node_modules/\|Workspace/sources/\|/venv/\|/.git/' > ws-files-and-dirs.txt

findЭто grepможет быть плохая форма, но это кажется самым прямым способом использования отрицательного фильтра регулярных выражений.

Следующая команда включает в себя только файлы в выводе find и заняла заметно больше времени.

% find Workspace/ -type f | grep -v '/vendor\|/node_modules/\|Workspace/sources/\|/venv/\|/.git/' > ws-files-only.txt

Я написал некоторый код для проверки производительности этих двух команд (с dashи tcsh, просто чтобы исключить любые эффекты, которые может иметь оболочка, даже если их не должно быть). Эти tcshрезультаты были опущены , поскольку они по существу то же самое.

Результаты, которые я получил, показали около 10% снижения производительности за -type f

Вот выходные данные программы, показывающие количество времени, необходимое для выполнения 1000 итераций различных команд.

% perl tester.pl
/bin/sh -c find Workspace/ >/dev/null
82.986582

/bin/sh -c find Workspace/ | grep -v '/vendor\|/node_modules/\|Workspace/sources/\|/venv/\|/.git/' > /dev/null
90.313318

/bin/sh -c find Workspace/ -type f >/dev/null
102.882118

/bin/sh -c find Workspace/ -type f | grep -v '/vendor\|/node_modules/\|Workspace/sources/\|/venv/\|/.git/' > /dev/null

109.872865

Протестировано с

% find --version
find (GNU findutils) 4.4.2
Copyright (C) 2007 Free Software Foundation, Inc.

На Ubuntu 15.10

Вот скрипт Perl, который я использовал для бенчмаркинга

#!/usr/bin/env perl
use strict;
use warnings;
use Time::HiRes qw[gettimeofday tv_interval];

my $max_iterations = 1000;

my $find_everything_no_grep = <<'EOF';
find Workspace/ >/dev/null
EOF

my $find_everything = <<'EOF';
find Workspace/ | grep -v '/vendor\|/node_modules/\|Workspace/sources/\|/venv/\|/.git/' > /dev/null
EOF

my $find_just_file_no_grep = <<'EOF';
find Workspace/ -type f >/dev/null
EOF

my $find_just_file = <<'EOF';
find Workspace/ -type f | grep -v '/vendor\|/node_modules/\|Workspace/sources/\|/venv/\|/.git/' > /dev/null
EOF

my @finds = ($find_everything_no_grep, $find_everything,
    $find_just_file_no_grep, $find_just_file);

sub time_command {
    my @args = @_;
    my $start = [gettimeofday()];
    for my $x (1 .. $max_iterations) {
        system(@args);
    }
    return tv_interval($start);
}

for my $shell (["/bin/sh", '-c']) {
    for my $command (@finds) {
        print "@$shell $command";
        printf "%s\n\n", time_command(@$shell, $command);
    }
}

GNU find имеет оптимизацию, которую можно применять, find .но не к ней find . -type f: если он знает, что ни одна из оставшихся записей в каталоге не является каталогами, он не будет определять тип файла (с помощью statсистемного вызова), если только один из критерии поиска требуют этого. Вызов statможет занять измеримое время, так как информация обычно находится в inode, в отдельном месте на диске, а не в директории, содержащей ее.

Как это узнать? Потому что количество ссылок на каталог указывает, сколько у него подкаталогов. В типичных файловых системах Unix количество ссылок на каталог равно 2 плюс количество каталогов: один для записи каталога в его родительском элементе, один для .записи и один для ..записи в каждом подкаталоге.

-noleafОпция говорит findне применять эту оптимизацию. Это полезно, если findвызывается в некоторой файловой системе, где количество ссылок на каталоги не соответствует соглашению Unix.