Не думаете ли вы, что если бы существовал язык сценариев быстрее, чем lua и python, то о нем говорили бы, по крайней мере, столько же, сколько и они?
Скорость языка сценариев довольно расплывчато. Языки сценариев по сути преобразуются в серию вызовов функций, написанных на быстро скомпилированных языках. Но функции обычно пишутся так, чтобы они были общими с большим количеством проверок и отказов, а не быстрыми. Для некоторых проблем не много избыточных действий складывается, и перевод сценария приводит к по существу тому же машинному коду, что и у скомпилированной программы. Что касается других проблем, человек, хорошо знающий язык, может заставить его перевести его на практически такой же машинный код. Для других задач цена удобства остается навсегда со сценарием.
Если вы посмотрите на сроки тестовых заданий , вы обнаружите, что среди них нет последовательного победителя. Для одной задачи язык самый быстрый, для другой - далеко позади.
Было бы целесообразно измерить скорость языка в вашей задаче, посмотрев аналогичные задачи в тестах. Итак, какая из этих проблемных карт ближе всего к вашей? Мое предположение будет: нет.
Теперь к вопросу о пользовательских программах внутри вашей программы.
Вот так и появились языки сценариев. Вы можете прочитать, почему такой язык может быть медленным, например, в SICP.
Если вы оцениваете то, что, как вы ожидаете, люди будут писать в своих программах, вы можете решить, что вам не нужно давать им полный язык программирования. Затем вы можете дать им простой набор инструкций, которые они могут использовать для описания нескольких решений ветвления и поиска значений. Тогда ваша собственная очень производительная программа создаст объект, который охватывает описанную логику. Этот трик описан здесь и там .
Однако, если вы продолжите добавлять все более и более сложные команды для вызова пользователей, вы просто придумаете свой собственный собственный язык . В этот момент вы, вероятно, захотите, чтобы вы пошли с Луа с самого начала.
При этом, я не думаю, что приведенный ниже фрагмент будет существенно отличаться в скомпилированном коде, вашем собственном объекте интерпретатора или любом встроенном языке сценариев:
if event = "You have just been instructed to go to X":
set_front_of_me(X) # call your function
n = how_many_people_are_in_front_of_me() #call to your function
if n > 3:
move_to_side() #call to function provided by you
else:
move_forward() #call to function provided by you
Теперь, если пользователям нужно будет выполнять сложные компьютерные задачи, решать np-задачи, выполнять машинное обучение или другие умножения матриц, тогда да, это будет медленно, если кто-то действительно будет беспокоиться о реализации этого.
Если вы дошли до этого момента, похоже, что есть хотя бы некоторые возможности для песочницы скомпилированных dll (по крайней мере, в некоторых языках). Или вы можете самостоятельно выполнить компиляцию пользовательского кода, чтобы контролировать функционирование, которое они вызывают, а затем подключить его как библиотеку.