Есть ли способ увеличиться, 'находят' скорость

mpirun вероятно, использование execv() звоните для запущения программы вместо execvp() один (который искал бы его в PATH).

Первое обходное решение: спросите оболочку к поиску для команды отдельно:

mpirun -np 4 $(which PyroDist) -in C005.dat -out foo

Иначе: два (не настолько хороший) обходные решения я могу думать:

  1. Использовать /usr/bin/env с аргументом PyroDist, но это требует этого mpirun позволяет передавать аргументы наряду с программой так или иначе.

  2. Запишите свою собственную обертку как:

    #!/bin/sh
    PyroDist
    

    и поместите его куда-нибудь с “фиксированным” относительным путем.

15
13.06.2012, 00:58
7 ответов

Попытайтесь использовать locate, это должно сделать то, что Вы хотите.

15
27.01.2020, 19:49
  • 1
    Обычно хорошая идея изложить в деталях ответ немного больше. Как упоминание, что пакет locate прибывает из (обычно slocate), и использовать updatedb для восстановления DB. :-) –  Patrick 13.06.2012, 03:43
  • 2
    Обычно хорошая идея изложить в деталях ответ немного больше. Как упоминание, что пакет locate прибывает из (обычно slocate), и использовать updatedb для восстановления DB. :-) –  Patrick 13.06.2012, 03:43
  • 3
    Это не работает на разделы с выключенной индексацией. Например, разделы NTFS страдают от плохой производительности, если индексация будет включена, таким образом найдите, то не будет работать на тех, "как она должна". –  ojrask 27.11.2015, 08:52

Это зависит очень от того, каков Ваш критерий поиска.

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

Но с находкой можно искать размер файла, возраст файла и другие вещи, которые не доступны для поиска, располагаются.

Если Вы знаете, где искать, можно использовать путь для разграничивания поискового объема:

find /some/path -size -10M -size +2M -mtime -365 ...

только искал бы файлы от 2 до 10 М, максимального 1 года в/some/path.

Программы, доступные в пути, могут искаться который, справка, lib и конфигурационные файлы с whereis. Примеры:

which java
/usr/bin/java

whereis firefox 
firefox: /usr/bin/firefox /etc/firefox /usr/lib/firefox /usr/share/firefox /usr/share/man/man1/firefox.1.gz
9
27.01.2020, 19:49

Это зависит очень от того, каков Ваш критерий поиска.

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

Но с находкой можно искать размер файла, возраст файла и другие вещи, которые не доступны для поиска, располагаются.

Если Вы знаете, где искать, можно использовать путь для разграничивания поискового объема:

find /some/path -size -10M -size +2M -mtime -365 ...

только искал бы файлы от 2 до 10 М, максимального 1 года в/some/path.

Программы, доступные в пути, могут искаться который, справка, lib и конфигурационные файлы с whereis. Примеры:

which java
/usr/bin/java

whereis firefox 
firefox: /usr/bin/firefox /etc/firefox /usr/lib/firefox /usr/share/firefox /usr/share/man/man1/firefox.1.gz
9
27.01.2020, 19:49

Использовать locate

Причина - это locate использует базу данных всех существующих каталогов и файлов, это было уже создано точно так же, как Вы вообразили!
http://linux.about.com/od/commands/l/blcmdl5_locatedb.htm

В некотором наборе (и изменяемый) интервал, который делают прогоны задания, сканирует файловую систему и затем создает базу данных с ним. Затем эта база данных (locatedb), с ее соответствующими индексами locate команда идет вразрез вместо того, чтобы сканировать через Ваш жесткий диск в той точке.

Таким образом, позитивный аспект - то, что это очень быстро по сравнению со сканированием жесткого диска. Оборотная сторона - то, что определять местоположение база данных (locatedb) не 'жива', так может только использоваться для файлов, которые существовали 'с' последнего сканирования.

Обновить locatedb, теперь выполненный updatedb (или sudo updatedb при необходимости)

btw я просто работал sudo updatedb локально и потребовалось 3 1/2 секунды! У меня есть 31 000 файлов.

7
27.01.2020, 19:49

Использовать locate

Причина - это locate использует базу данных всех существующих каталогов и файлов, это было уже создано точно так же, как Вы вообразили!
http://linux.about.com/od/commands/l/blcmdl5_locatedb.htm

В некотором наборе (и изменяемый) интервал, который делают прогоны задания, сканирует файловую систему и затем создает базу данных с ним. Затем эта база данных (locatedb), с ее соответствующими индексами locate команда идет вразрез вместо того, чтобы сканировать через Ваш жесткий диск в той точке.

Таким образом, позитивный аспект - то, что это очень быстро по сравнению со сканированием жесткого диска. Оборотная сторона - то, что определять местоположение база данных (locatedb) не 'жива', так может только использоваться для файлов, которые существовали 'с' последнего сканирования.

Обновить locatedb, теперь выполненный updatedb (или sudo updatedb при необходимости)

btw я просто работал sudo updatedb локально и потребовалось 3 1/2 секунды! У меня есть 31 000 файлов.

7
27.01.2020, 19:49

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

Однако для более сложных поисков Вы, вероятно, застреваете с находкой.

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

1
27.01.2020, 19:49

для одной операции поиска; Я не нашел ускорения; если вы не пытаетесь сузить область поиска с помощью параметров найти .

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

0
27.01.2020, 19:49

Теги

Похожие вопросы