Выбор языка сценариев для начальной производительности

Lua - это язык сценариев, который соответствует вашим критериям. Это, безусловно, самый быстрый язык сценариев с наименьшим объемом памяти.

При правильном написании C должен быть независимым от платформы и потребует только перекомпиляции для этих разных платформ. Возможно, вам придется перескакивать через несколько обручей #ifdef для заголовков (не все системы используют одни и те же заголовки), но большинство обычных (не связанных с Win32 API) вызовов очень переносимы. Для веб-доступа (который, как я полагаю, вам нужен, когда вы упоминаете bash + curl), вы можете взглянуть на libcurl, он доступен для всех упомянутых вами платформ, и работать с ним не должно быть так сложно.

Принимая во внимание время выполнения и стоимость памяти, я сомневаюсь, что вы могли бы работать быстрее, чем правильно написанный C с любым языком сценариев, поскольку вы потеряете по крайней мере некоторое время на интерпретацию сценария ...

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

Лично я бы использовал Ruby или Python для этого типа работы, они оба позволяют очень легко сделать понятный и понятный код, который могут поддерживать другие (или вы можете поддерживать, не глядя на него в течение 6 месяцев). Если у вас есть контроль, я бы также предложил получить последнюю версию интерпретатора, поскольку и Ruby, и Python в последнее время значительно улучшили производительность.

Это немного личное. Программирование на Ruby меня радует, а код на C - нет (как и создание сценариев на bash для чего-либо нетривиального).

Из-за ваших требований к быстрому запуску и частоте вызовов более 1 Гц я бы рекомендовал либо остаться с C и выяснить, как сделать его портативным (не всегда так просто, как несколько ifdef), либо изучить возможность превращения его в сервисный демон, который всегда запущен. Конечно, это зависит от того, как

У Python может быть меньшее время запуска, если вы скомпилируете модуль и запустите файл .pyc, но он по-прежнему считается медленным. По моему опыту, Perl - это самый быстрый из языков сценариев, так что, возможно, вам повезет с демоном Perl.

Вы также можете посмотреть кросс-платформенные фреймворки, такие как gtk, wxWidgets и Qt. Хотя они нацелены на графические интерфейсы, у них есть низкоуровневые кроссплатформенные типы данных и сетевые библиотеки, которые могут облегчить работу по использованию быстрого приложения на основе C.

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

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

Python хорош. Я бы также посмотрел на веб-сайт игры Computer Languages ​​Benchmarks Game:

http://shootout.alioth.debian.org/

Возможно, стоит потратить немного времени на изучение тестов (включая числа для времени запуска и использования памяти). Сравнивается множество языков, таких как Perl, Python, Lua и Ruby. Вы также можете сравнить эти языки с тестами на C.

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

Вы также можете довольно легко сделать это в Ruby и Perl (хотя и с некоторыми трудностями). Но не спрашивайте меня, как это сделать.

Я согласен с Lua: он суперпортативен, в нем есть библиотеки XML, собственные или связанные с библиотеками C, такими как Expat, у него есть хорошая библиотека сокетов (LuaSocket), плюс для сложных вещей, некоторые привязки cURL, и он хорошо известен за быть очень легким (часто встроенным в устройства с низким объемом памяти), очень быстрым (один из самых быстрых языков сценариев) и мощным. И очень легко кодировать!

Он написан на чистом Ansi C, и многие люди утверждают, что у него один из лучших API-интерфейсов для C (вызов подпрограмм C из Lua, вызов кода Lua из C ...).

«вызывается отовсюду от каждой минуты до множества раз в секунду. Как следствие, важно сохранять память и время запуска на низком уровне».

Для меня это совсем не похоже на сценарий.

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

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

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

Можете ли вы вместо этого сделать это длительным процессом и отвечать на запросы http или rpc?
Это удовлетворило бы требования к задержке практически в любом сценарии, но я не знаю, нарушит ли это ваши ограничения на объем памяти.

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

Неясно, предназначено ли это для обработки HTTP-запросов; в таком случае Perl имеет хороший модуль HTTP-сервера, привязки к нескольким различным анализаторам XML на основе C и невероятно быструю поддержку строк. (Если вы не хотите демонизировать, у него есть хороший полнофункциональный модуль CGI; если у вас есть полный контроль над сервером, на котором он работает, вы также можете использовать mod_perl для реализации вашего скрипта в качестве обработчика Apache.) Строки Ruby работают немного медленнее, но для этого есть несколько действительно хороших фоновых инструментов. Боюсь, что я не так хорошо знаком с Python, поэтому не могу дать никаких рекомендаций по этому поводу.

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

Dagny:~ brent$ time perl -MCGI -e0

real    0m0.610s
user    0m0.036s
sys     0m0.022s
Dagny:~ brent$ time perl -MCGI -e0

real    0m0.026s
user    0m0.020s
sys     0m0.006s

(Параметры интерпретатора Perl загружают довольно большой модуль CGI, а затем выполняют строку кода '0;'.)

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

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

Наконец, вы также упомянули, что это часть более крупного решения, тогда вы можете захотеть повторно использовать язык, возможности более крупных решений. Из приведенного вами описания (xml + http) кажется вполне обычным приложением, которое можно написать на любом универсальном языке (может быть, веб-контейнер на java?).

Некоторые библиотеки могут помочь вам сделать ваш код переносимым: Способствовать росту, Qt

более подробная информация может вызвать больше идей :)

Портируйте свое приложение на Ruby. Если ваше приложение слишком медленное, профилируйте его и перепишите эти части на C.