Tại sao `tìm. -type f` mất nhiều thời gian hơn `find .`?

Dường như findsẽ phải kiểm tra xem một đường dẫn cụ thể có tương ứng với một tệp hoặc thư mục hay không để đi theo cách đệ quy nội dung của các thư mục.

Đây là một số động lực và những gì tôi đã làm tại địa phương để thuyết phục bản thân rằng find . -type fthực sự chậm hơn find .. Tôi chưa đi sâu vào GNU tìm mã nguồn.

Vì vậy, tôi đang sao lưu một số tệp trong $HOME/Workspacethư mục của mình và loại trừ các tệp phụ thuộc vào các dự án hoặc tệp kiểm soát phiên bản của tôi.

Vì vậy, tôi đã chạy lệnh sau đó thực hiện nhanh chóng

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

findĐường ống grepcó thể là hình thức xấu, nhưng có vẻ như là cách trực tiếp nhất để sử dụng bộ lọc regex phủ định.

Lệnh sau chỉ bao gồm các tệp trong đầu ra của find và mất nhiều thời gian hơn.

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

Tôi đã viết một số mã để kiểm tra hiệu năng của hai lệnh này (với dashvà tcsh, chỉ để loại trừ bất kỳ hiệu ứng nào mà trình bao có thể có, mặc dù không nên có bất kỳ). Các tcshkết quả đã bị bỏ qua vì về cơ bản chúng giống nhau.

Kết quả tôi nhận được cho thấy mức phạt hiệu suất 10% cho -type f

Đây là đầu ra của chương trình hiển thị lượng thời gian cần thiết để thực hiện 1000 lần lặp của các lệnh khác nhau.

% 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

Đã thử nghiệm với

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

Trên Ubuntu 15.10

Đây là tập lệnh perl tôi đã sử dụng để đo điểm chuẩn

#!/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 có một tối ưu hóa có thể được áp dụng find .nhưng không phải find . -type f: nếu nó biết rằng không có mục nào còn lại trong thư mục là thư mục, thì nó không cần xác định loại tệp (với lệnh statgọi hệ thống) trừ khi một trong các tiêu chí tìm kiếm đòi hỏi nó. Việc gọi statcó thể mất thời gian có thể đo được vì thông tin thường ở trong nút, ở một vị trí riêng trên đĩa, thay vì trong thư mục chứa.

Làm sao nó biết? Bởi vì số lượng liên kết trên một thư mục cho biết nó có bao nhiêu thư mục con. Trên các hệ thống tệp Unix điển hình, số lượng liên kết của một thư mục là 2 cộng với số lượng thư mục: một cho mục nhập của thư mục trong cha mẹ của nó, một cho .mục nhập và một cho ..mục nhập trong mỗi thư mục con.

Các -noleaftùy chọn nói findkhông áp dụng tối ưu hóa này. Điều này hữu ích nếu findđược gọi trên một số hệ thống tập tin trong đó số lượng liên kết thư mục không tuân theo quy ước Unix.