Ускорение работы скрипта с помощью fastEntireScript и entireScript

  • Автор темы Автор темы veretragna
  • Дата начала Дата начала

veretragna

γνώσις
Топикстартер
Сообщения
578
Реакции
200
Можно поступить проще.
Функции в InDesign можно задать режим выполнения entireScript, а есть еще fastEntireScript. Разница между ними не документирована, но fastEntireScript работает иногда в десятки раз быстрее.
У fastEntireScript есть недостатки - если попытаться откатить последнее действие скрипта, могут заодно откатиться и некоторые действия пользователя, которые были сделаны перед скриптом, поэтому широко его не применяют.

Моя гипотеза: entireScript создает контрольные точки (snapshots) на каждом шаге выполнения скрипта, поэтому его скорость не так уж высока. fastEntireScript контрольных точек не создает и прогоняет скрипт как бы в одну цельную транзакцию, но если движок не видит смысла создавать новую транзакцию, он запишет действия в старую и при откате будут непредсказуемо откатываться и действия пользователя.

Это можно обойти вот так, завернув вызов с режимом fastEntireScript в вызов с режимом entireScript.
entireScript гарантированно создаст новую транзакцию, а fastEntireScript быстро ее провернет как одно целое.
JavaScript:
function main() {
    // код
}

app.doScript(
    "app.doScript(main,undefined,undefined,UndoModes.fastEntireScript);",
    ScriptLanguage.JAVASCRIPT,
    undefined,
    UndoModes.entireScript
);

Пользуюсь этим методом где-то год, на операциях с текстом ускорение сильно чувствуется.
Изначально трюк подсмотрен на сайте indiscripts.com.

Должен заметить, что оборачивать вызовы таким образом нужно только после тщательной отладки, doScript в целом для отладки не очень приятен, а двойная обертка добавляет остроты ощущений.
 
  • Спасибо
Реакции: azz и catpaw
Можно поступить проще.
Функции в InDesign можно задать режим выполнения entireScript, а есть еще fastEntireScript. Разница между ними не документирована, но fastEntireScript работает иногда в десятки раз быстрее.
У fastEntireScript есть недостатки - если попытаться откатить последнее действие скрипта, могут заодно откатиться и некоторые действия пользователя, которые были сделаны перед скриптом, поэтому широко его не применяют.

Моя гипотеза: entireScript создает контрольные точки (snapshots) на каждом шаге выполнения скрипта, поэтому его скорость не так уж высока. fastEntireScript контрольных точек не создает и прогоняет скрипт как бы в одну цельную транзакцию, но если движок не видит смысла создавать новую транзакцию, он запишет действия в старую и при откате будут непредсказуемо откатываться и действия пользователя.

Это можно обойти вот так, завернув вызов с режимом fastEntireScript в вызов с режимом entireScript.
entireScript гарантированно создаст новую транзакцию, а fastEntireScript быстро ее провернет как одно целое.
JavaScript:
function main() {
    // код
}

app.doScript(
    "app.doScript(main,undefined,undefined,UndoModes.fastEntireScript);",
    ScriptLanguage.JAVASCRIPT,
    undefined,
    UndoModes.entireScript
);

Пользуюсь этим методом где-то год, на операциях с текстом ускорение сильно чувствуется.
Изначально трюк подсмотрен на сайте indiscripts.com.

Должен заметить, что оборачивать вызовы таким образом нужно только после тщательной отладки, doScript в целом для отладки не очень приятен, а двойная обертка добавляет остроты ощущений.


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

В сабже по-моему особо ускорять нечего, должно выполняться в момент. лучше разобраться что там вешается. А еще кстати на фрейм можно autofit повесить
 
  • Спасибо
Реакции: catpaw
Мне тоже весьма странно, что в приложенном участке кода так тормозить может
 
Способ давно известный. И кто-то мне тут помнится доказывал что ничего он ускорять не может и это полный бред, с хорошей аргументацией )

В сабже по-моему особо ускорять нечего, должно выполняться в момент. лучше разобраться что там вешается. А еще кстати на фрейм можно autofit повесить
Нашел комментарии andrew.folio от 2013 года, по поводу скорости он как раз не спорит и пишет " В режиме FAST_ENTIRE_SCRIPT ради скорости система полностью снимает с себя контроль над процессом выполнения".
У него основные претензии к безопасности.
Вы эту тему имеете ввиду?
 
Последнее редактирование модератором:
Нашел комментарии andrew.folio от 2013 года, по поводу скорости он как раз не спорит и пишет " В режиме FAST_ENTIRE_SCRIPT ради скорости система полностью снимает с себя контроль над процессом выполнения".
У него основные претензии к безопасности.
Вы эту тему имеете ввиду?


Вот же:
Так и скорость выполнения тогда будет как при ENTIRE_SCRIPT. Смысла оборачивать вообще не вижу.
 
Последнее редактирование модератором:
Вот же:
Так и скорость выполнения тогда будет как при ENTIRE_SCRIPT. Смысла оборачивать вообще не вижу.

Хотя это может я и напутал. Дело давно было. Но вроде как по ссылке еще написано что начиная с cs5 вложенность не нужна
 
Хотя это может я и напутал. Дело давно было. Но вроде как по ссылке еще написано что начиная с cs5 вложенность не нужна
Взял первый попавшийся скрипт, который меняет размер текста в документе, и первый попавшийся документ на ~120 страниц, пропустил с таймером в трех режимах fastEntireScript, entireScript и обернутый.
После каждого пробега делал Revert документа, перед тестами отключил Preflight и Redraw для чистоты эксперимента.
Каждый тест провел 3 раза, приведены результаты третьего пробега, чтобы исключить догрузки-прогрузки и т.д.

Обернутый: 24.87 сек
entireScript: 102.27 сек
fastEntireScript: 24.46 сек

Выводы.
  1. Гражданин, вероятно, недостаточно тщательно тестировал эти режимы. Если fastEntireScript обернут в entireScript, он не может быть проигнорирован, поскольку вызывается первым.
  2. У обертки есть небольшой оверхед, вероятно, на принудительное создание новой контрольной точки.
  3. entireScript проигрывает более чем в 4 раза и fastEntireScript, и обертке.
 
Последнее редактирование:
Тот же документ, но взял другой скрипт, который применяет к документу цепочку грепов.
Обернутый: 14.35 сек
entireScript: 13.58 сек
fastEntireScript: 13.53 сек

Выводы:
  1. Оверхед никуда не делся, но списать его на создание новой контрольной точки уже не получается. Видимо, это оверхед на вложенное исполнение или JIT-компиляцию, что в принципе две стороны одного явления.
  2. С грепами основную работу выполняет движок индизайна, а не скрипт. Скрипт только формирует и скармливает ему грепы и настройки поиска-замены, поэтому никакого выигрыша от fastEntireScript или обертки при работе с грепом нет.
 
 
А я померял скорость [на глазок))], вроде бы раза в два побыстрее стало. Правда без оберток - напрямую (VBA)
MyValue = myInd.DoScript(myJavaScriptString, idScriptLanguage.idJavascript, , idUndoModes.idFastEntireScript)
Есть занудный скрипт очистки от мусора. Вот на нем и почувствовал. Хотя можно и секундометром померяться)).
 
В индизайне есть VBA?