Чому `знаходить. -тип 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 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 . -type f: якщо вона знає, що жодна з решти записів у каталозі не є каталогами, то визначати тип файлу (із statсистемним викликом) не турбується, якщо один із критерії пошуку цього вимагають. Виклик statможе зайняти вимірюваний час, оскільки інформація, як правило, знаходиться в inode, в окремому місці на диску, а не в каталозі, що містить.

Звідки це знати? Оскільки кількість посилань у каталозі вказує, скільки у них є підкаталогів. У типових файлових системах Unix кількість посилань каталогів становить 2 плюс кількість каталогів: один для запису каталогу в його батьківському, один для .запису та один для ..запису у кожному підкаталозі.

Цей -noleafпараметр повідомляє findне застосовувати цю оптимізацію. Це корисно, якщо findйого викликають у деякій файловій системі, де кількість посилань каталогів не відповідає конвенції Unix.