облегченная библиотека сценариев C ++

Question

В настоящее время я использую QtScript для функций сценариев в моем приложении C ++, но это довольно "тяжело" для процессора. Когда поток оценивает все скрипты в цикле, загрузка процессора увеличивается до 90% -100%. Даже когда я кладу его в спящий режим на 1 мсек каждые 5 сценариев, он остается выше 75% загрузки процессора.

Существуют ли какие-либо другие простые в реализации скриптовые среды, которые намного легче QScript?

редактирование:

Теперь я понимаю, что это нормальное поведение, а не какая-то ошибка в QtScript. Тем не менее, интересно узнать, какие виды (облегченных) библиотек сценариев доступны.

Answer 1

Посмотрите на Lua , он часто используется в играх, поэтому производительность должна быть довольно хорошей.

Answer 2

Ну, что вы ожидаете? Если сценарий не должен ожидать дискового или пользовательского ввода-вывода, процессор должен работать на 100%.

Ваша проблема в том, что она долго работает?

Или что ваше приложение не отвечает?

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

[править]
Немного другой вопрос: процессор на 100% при отсутствии сценария для обработки?

100% ЦП хорош и исправен, если вы что-то обрабатываете.

Процессор всегда занят, текущий поток всегда потребляет 100% ядра, на котором он работает. «Активность процессора 0%» фактически означает, что все циклы проводятся в потоке системного простоя (который относится к «процессу простоя системы», который вы видите в диспетчере задач).

В качестве упрощенного примера: если у вас активен один поток приложения и загрузка ЦП составляет 40%, а интервал обновления диспетчера задач составляет 1 с, 400 мс времени ЦП было потрачено на приложение, а 600 мс - на незанятый поток.

Answer 3

Lua хорош, потому что он использует стек для связи между интерпретатором и C ++. Это хорошо, потому что это не включает в себя подсчет ссылок, видимый вам, что упрощает вещи.

Вот интересное сравнение в качестве фона для некоторого языка: Язык языка .

Answer 4

Я бы лично порекомендовал Lua, если бы он широко использовался на нашей встроенной платформе. Если вы работаете в Windows, вы можете использовать что-то вроде LuaJIT, чтобы сделать ваш Lua еще быстрее

Однако, поскольку никто не упомянул об этом, вы также можете взглянуть на Белку (http://squirrel -lang.org / ). У меня не было никакого опыта с этим, но я думаю, что это выглядит многообещающим.

Что касается вашей текущей проблемы, любой код займет 100% ЦП, если у него нет ничего, что могло бы его заблокировать.

что-то вроде (псевдокод):

для (я = 1,10000000000000) п = п + я конец

будет занимать 100% ЦП, пока он не завершит работу (почти) на любом языке, потому что ничто не мешает его выполнению.

Answer 5

Я слышал хорошие вещи о TinyScheme . Как уже было сказано, мы используем Lua здесь (в студии разработки игр, ориентированной на встраиваемые и портативные системы).

Следует отметить, что - особенно с Lua, но я думаю, что они применимы ко многим из следующих языков:

• Пользовательский легкий распределитель небольших объектов может значительно повысить производительность; многие из этих языков очень тяжелые. Использование пула или распределителя на основе фреймов может стоить вашего времени, в зависимости от того, с чем вы можете справиться.
• В зависимости от используемой стратегии GC (поскольку большинство этих языков являются сборщиком мусора), вам может понадобиться небольшая область сканирования GC - например, маленький размер кучи Луа в целом. Можно потратить некоторое время на реорганизацию данных, чтобы вывести их за пределы домена GC (например, сохранить их на стороне C ++, пометить их каким-либо образом, чтобы GC знал, как этого избежать, и т. Д.).
• Аналогично, инкрементная сборка мусора может быть большой победой. Я бы порекомендовал поэкспериментировать - в некоторых случаях (небольшая куча) я обнаружил полный сборщик мусора быстрее, чем добавочный.

Answer 6

Lua ваш язык по вашему выбору . Для Qt .

существует несколько привязок.

Answer 7

Это действительно зависит от нескольких факторов:

• Будет ли сценарий часто использоваться в вашем приложении?
• Будут ли сценарии сложными?
• Вы предоставляете много функций для скриптового движка?
• Вам нужна хорошая интеграция в Qt?

Я также рекомендую Lua, однако вам следует помнить следующее: Lua реализован в чистом ANSI C. Это делает его сверхпортативным, но если вы разрабатываете в среде C ++, это приведет к большому «обёртывания» классов. Особенно, если вы хотите показать функциональность Qt (со всеми SIGNAL s, SLOT s и PROPERTY s), это приводит к большому количеству дублирующегося кода.

Answer 8

Ничего плохого в QtScript из того, что я могу сказать до сих пор (только начал использовать его с 4.6, так что все еще плохо знаком с ним, но мне пока нравится). Зависит от того, как вы используете его, как Луа или Питон. Если вы сохраняете основную функциональность ядра своего приложения (скомпилированную из c / c ++) и предоставляете только минимальный API для механизма сценариев, то, в общем, вы можете сделать все быстро.

С QtScript относительно легко экспонировать объекты и их методы разумно поточно-ориентированным способом (слоты QT и объектная модель сигналов) и легко передавать созданные скриптом объекты в нативные функции ... но в итоге вы можете быть тесно интегрированы со средой QT (что иногда может быть именно тем, что вы хотите).

Если вы хотите произвольно представить нативные объекты c ++ для других встроенных сред сценариев, проверьте SWIG . SWIG похож на инструмент toLua, но работает для многих встраиваемых языков, таких как lua, c #, tcl, java и python . Исходя из опыта, ToLua сделал связывание объектов и методов со скриптами гораздо менее болезненным процессом, и я также не слышал много плохих вещей о SWIG.

Answer 9

Вы также можете встраивать javascript с помощью spidermonkey Я думаю, что javascript более распространен, чем lua.