Расширение параметра Bash: лучшие практики для скорости?

Может показаться, что prefix-* должно быть легко превратить, например, в prefix-1 prefix-2, так как мы привыкли видеть отсортированные списки каталогов. Но оказывается, что очень немногие файловые системы могут на самом деле создавать отсортированные списки имен файлов, и, кроме того, не существует стандартного API для запроса отсортированных списков имен файлов.

Если программа - такая как ls или, в этом отношении, bash - нужен список имен файлов, он должен прочитать весь список каталогов, который будет создан в некотором случайном порядке (часто порядок связан со временем создания; иногда он основан на хэше имени файла; но в большинстве случаев нет дело это простой алфавитный порядок). Итак, чтобы решить prefix-* Вам нужно прочитать весь каталог и проверить каждое имя файла по шаблону. Поскольку наиболее дорогостоящей частью этой процедуры является чтение каталога, не имеет значения, насколько сложен шаблон или сколько имен файлов соответствуют шаблону.

В итоге, расширение имени пути ("разрешения глобусов") будет медленным в большом каталоге. Это причина избегать больших каталогов, а не причина избегать глобусов.

Но есть еще одно важное назначение данных: prefix-{1,2} не расширение пути Это " расширение скобок " и расширение стандарта оболочки Posix (хотя его реализуют практически все оболочки). Существует несколько различий между расширением скобок и расширением пути, но одно важное и важное различие заключается в том, что расширение скобок не зависит от существования файлов. Разбивка скобок - это простая строковая операция.

Как следствие, prefix-{1,2} всегда будет расширяться до prefix-1 prefix-2 независимо от того, существуют эти файлы или нет. Это означает, что он может быть расширен без чтения каталога и без stat в любом файле. Понятно, что это будет быстро. Но есть и обратная сторона: невозможно определить, соответствует ли результат реальным файлам.

Рассмотрим следующий простой пример:

$ mkdir test && cd test
$ touch file1 file2 file4
$ ls file*
file1 file2 file4
$ ls file[1234]
file1 file2 file4
$ ls file{1,2,3,4}
ls: cannot access file3: No such file or directory
file1 file2 file4

Конечный момент: расширение пути выполняется оболочкой, а не ls, С расширением пути мы могли бы также использовать echo:

$ echo file*
file1 file2 file4
$ echo file[1234]
file1 file2 file4

А также echo будет производить список несколько быстрее, потому что все echo нужно сделать, это распечатать свои аргументы, в то время как ls (который получает те же аргументы) должен stat каждый аргумент, чтобы убедиться, что это файл. Тот stat - который не является дешевым вызовом - полностью избыточен в случае расширения пути, потому что оболочка уже использовала список каталогов для фильтрации списка файлов и, следовательно, каждое имя файла передавалось ls как известно, существует. (Если глобус не совпадал ни с какими файлами.)

Кроме того, эхо является bash встроенный, поэтому он может быть вызван без создания дочернего процесса.

В случае расширения скобки, тем не менее, echo не дает тот же результат:

$ echo file{1,2,3,4}
file1 file2 file3 file4

Таким образом, мы могли бы использовать ls, перенаправляя вывод ошибок в область битов:

$ ls file{1,2,3,4}
file1 file2 file4

и в этом случае stat вызовы не являются избыточными, потому что оболочка никогда не проверяла имена файлов.

Если ваши каталоги не очень большие, ничего из этого не будет иметь большого значения, и глоб будет намного легче писать. Если ваши каталоги действительно огромны, вам следует рассмотреть возможность их разделения на более мелкие подкаталоги.

Например, вместо путей вроде:

/var/log/remote/serverX.domain.local/ps/ps2.log.2014-mm-dd.gz

Вы можете использовать:

/var/log/remote/serverX/domain.local/ps/ps2.log.2014-mm-dd-gz

И если вы храните журналы навсегда, вы можете извлечь год, чтобы избежать бесконечно увеличивающегося размера каталога:

/var/log/remote/2014/serverX/domain.local/ps/ps2.log.2014-mm-dd-gz

(2014 намеренно повторяется.)

Разделение каталогов, как правило, будет большой победой, поскольку оно обеспечивает механизм для оптимизации глобализации. Как уже упоминалось выше, оболочка не может оптимизировать

/var/log/remote/server[2357].domain.local/ps/ps2.log.2014-10-*-gz

но это может оптимизировать

/var/log/remote/server[2357]/domain.local/ps/ps2.log.2014-10-*-gz

Во втором случае server[2357] нужно только сопоставить с именами каталогов, и как только это будет сделано, ps2.log.2014-10-*-gz нужно сопоставлять только с именами файлов в соответствующих каталогах.