Сравнение производительности сценариев оболочки и интерпретируемых языков высокого уровня (C # / Java / и т. Д.)

Question

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

Пропуск деталей - я просто хотел бы узнать и найти результаты тех, кто провел некоторые сравнения производительности Shell vs [вставьте сюда язык программирования общего назначения (интерпретируемый)), например, C # или Java ...

Удивительно, но я потратил некоторое время на поиск в Google, чтобы не найти никаких этих данных. Кто-нибудь когда-либо делал эти сравнения в разных вариантах использования; попадание в базу данных, как в циклах XYX #, выполняющих различные типы SQL (Oracle pref, но MSSQL будет делать) запросы, такие как любые операции CRUD, - а также не попадание в базу данных и просто обычное сравнение типов циклов 50k, выполняющее различные типы вычислений и тому подобное?

В частности - сейчас мне нужно сравнить попадание в БД Oracle из сценария оболочки по сравнению с, скажем, C # (опять же, любой интерпретируемый GPPL будет в порядке, даже более высокого уровня, например, Python). Но мне также нужно знать о стандартных программных вычислениях / инструкциях / и т.д ...

Прежде чем спросить «почему бы просто не написать быстрый тест самостоятельно? Ответ таков: я был разработчиком Windows всю свою жизнь / карьеру, и у меня очень ограниченные знания сценариев Shell - не говоря уже о * nix в целом ... Поэтому задаю вопрос здесь более опытным парни были бы очень полезны, не говоря уже об экономии времени, так как мы находимся в почти вечном крайнем сроке, как это;).

Answer 1

Давным-давно, вы когда-нибудь великий Shootout Computer Language Shootout включал некоторые сценарии оболочки.

Итак, любезно предоставлено Интернет-архивом, с 2004 года -

Примечание в сценариях оболочки не было программ для многих тестов.

    Score Missing-Tests

Java 20     1

Perl 16     0

Python 16   0

gawk 12     6 

mawk 10     6 

bash 7      12  

Примечание Сценарии оболочки иногда могут быть небольшими и быстрыми :-)

«Перевернуть файл»

        CPU (sec)   Mem (KB)    Lines Code

bash    0.0670      1464        1

C gcc   0.0810    4064        59

Python  0.3869    13160       6

Answer 2

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

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

Тем не менее, Python или Perl будут намного быстрее, чем скрипт оболочки, новиртуальная машина или собственный код будет еще быстрее.

Поскольку вы не можете нам сообщить какие-либо подробности, мы не можем предоставить конкретную помощь.

Если вы хотите увидеть простую демонстрацию длясравните, попробуйте мою реализацию pure-Bash hexdump и сравните ее с реальной вещью:

$ time ./bash-hexdump /bin/bash > /dev/null
real    7m17.577s
user    7m2.570s
sys     0m14.745s
$ time hexdump -C /bin/bash > /dev/null
real    0m2.459s
user    0m2.260s
sys     0m0.176s

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

$ time ./hexdump.py /bin/bash > /dev/null
real    0m11.694s
user    0m11.605s
sys     0m0.040s

Answer 3

Мне просто хотелось бы узнать и найти результаты тех, кто провел некоторые сравнения производительности ...

Неизменным уроком таких сравнений является то, что конкретные детали имеют значение- много.

Не только конкретные детали задачи, но (если мы не знаем это как программисты) конкретные детали написания сценария оболочки.

Так что вы можетенайти кого-то, кто понимает этот язык оболочки и может проверить, что сценарий оболочки был написан эффективным способом?(Было бы неплохо, если бы изменение пары строк заняло от 40 до 5 минут.)

Answer 4

Хотя сюда не входят языки «Shell» (он же sh / bash / ksh / powerscript), это довольно большой список «производительности языка [реализации]», полный общностей и предупреждений.В любом случае кому-то это может понравиться.

http://benchmarksgame.alioth.debian.org/

Answer 5

Только что выполнил этот очень простой тест в моей системе, и результаты оказались ожидаемыми.

Сложите все целые числа от 1 до 50 000 и выведите ответ на каждом шаге

Bash: 3 секундыC: 0,5 секунды

Answer 6

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

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

Опять же (без особых подробностей в вопросе) я бы начал с изучения различных компонентов системы, чтобы определить, какое из них является узким местом.

Answer 7

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

Но ... из-за закона Мура, увеличивающего вычислительную мощность каждые 18 месяцев, я задаюсь вопросом: действительно ли необходимы требования к производительности? Даже интерпретируемый код работает невероятно быстро на большинстве современных систем, и со временем он только улучшится. Вам действительно нужны улучшения скорости, которые даст вам скомпилированный код?

Если ответ отрицательный, то напишите, что вас радует.