Действительно ли возможно записать сценарий оболочки, который быстрее, чем эквивалентный сценарий в Perl? [закрытый]
5 ответов
Есть несколько способов ускорить выполнение вашей оболочки (например, Bash).
- Старайтесь использовать меньше внешних команд, если внутреннее устройство Bash может выполнить задачу
за вас. Например, чрезмерное использование
sed,grep,awkи т.д. для обработки строк / текста . - Если вы работаете с относительно БОЛЬШИМИ файлами, не используйте цикл while в bash. Используйте awk. Если вы работаете с действительно БОЛЬШИМИ файлами, вы можете использовать grep для поиска нужных шаблонов, а затем передать их в awk для «редактирования». Алгоритм поиска grep очень хороший и быстрый. Если вы хотите получить только начало или конец файла, используйте head и tail.
- инструменты для работы с файлами, такие как sed, cut, grep, wc и т. Д., Все можно сделать
с помощью одного скрипта awk или с использованием внутренних компонентов Bash, если это не сложно. Таким образом, вы можете попытаться сократить использование этих инструментов, которые частично совпадают по своим функциям.
Каналы / цепочки Unix - это превосходно, но использование их слишком большого количества,
например,
command | grep | grep | cut | sedзамедляет ваш код. Каждая труба - это накладные расходы. В этом примере все они выполняются одной awk.команда | awk '{сделайте все здесь}'Самый близкий инструмент, который вы можете использовать, который может соответствовать скорости Perl для определенных задач, например, обработки строк или математики, - это awk. Вот забавный тест для этого решения . В файле около 9 миллионов чисел
Вывод
$ head -5 file
1
2
3
34
42
$ wc -l <file
8999987
# time perl -nle '$sum += $_ } END { print $sum' file
290980117
real 0m13.532s
user 0m11.454s
sys 0m0.624s
$ time awk '{ sum += $1 } END { print sum }' file
290980117
real 0m9.271s
user 0m7.754s
sys 0m0.415s
$ time perl -nle '$sum += $_ } END { print $sum' file
290980117
real 0m13.158s
user 0m11.537s
sys 0m0.586s
$ time awk '{ sum += $1 } END { print sum }' file
290980117
real 0m9.028s
user 0m7.627s
sys 0m0.414s
Для каждой попытки awk быстрее Perl.
Наконец, постарайтесь выучить awk за пределами того, что они могут делать в одиночку.
Это может оказаться опасно близким к оптимизации в кресле, но вот несколько идей, которые могут рационализировать ваши результаты:
Fork / exec: почти все полезное, что выполняется сценарием оболочки, выполняется через оболочку, который запускает новую оболочку и выполняет команду, такую как
sed,awk,catи т. д. Чаще всего выполняется более одного процесса, и данные перемещаются по трубам.Структуры данных: структуры данных Perl более сложные, чем структуры Bash или Csh. Обычно это заставляет программиста работать с хранилищем данных. Это может принимать следующие формы:
- использовать неоптимальные структуры данных (массивы вместо хэшей);
- хранить данные в текстовой форме (например, целые числа как строки), которые необходимо каждый раз интерпретировать заново.
- сохранять данные в файл и повторно анализировать их снова и снова.
- и др.
Неоптимизированная реализация: некоторые конструкции оболочки могут быть спроектированы не с учетом оптимизации, а с учетом удобства пользователя. Например, у меня есть основания полагать, что реализация bash расширения параметров, в частности
$ {foo // search / replace}, является неоптимальной по сравнению с той же операцией вsed. Обычно это не проблема для повседневных задач.
Нет, я думаю, что это невозможно:
Команда bash - это действительно интерпретируемый язык, но программы Perl компилируются в байт-код перед выполнением
Да. Код C будет быстрее, чем код Perl для того же самого, поэтому сценарий, который использует скомпилированный исполняемый файл для выполнения большого количества работы, будет быстрее, чем программа Perl, выполняющая то же самое.
Конечно, программа Perl может быть переписана для использования исполняемого файла, и в этом случае она, вероятно, снова будет быстрее.
Некоторые команды оболочки в некоторых ситуациях могут выполняться быстрее, чем Perl. Однажды я сравнил простой скрипт sed с эквивалентом в Perl, и sed победил. Но когда требования стали более сложными, версия на perl начала превосходить версию sed. Так что ответ в зависимости от обстоятельств. Но по другим причинам (простота, ремонтопригодность и т. Д.) Я все равно склоняюсь к тому, чтобы делать что-то на Perl, если только требования не очень простые, и я ожидаю, что они останутся такими.