Copy link to clipboard
Copied
I have been reworking my CEP extensions into UXP plugins. Today I decided to do a speed test on the same process using the 2 different versions. The CEP version finished the work in 14 seconds. UXP did the same process in 2 minutes and 45 seconds. The processes are basically identical in the coding. Is it that UXP is not as optimized yet?
@John D Herzog I don't have full context on this, but I presume that your plugin's inline code calls into InDesign DOM APIs heavily. If this is the case and this code is executing inline within the plugin's business logic, they aren't executed on priority. This could be the reason for the delay you see.
To overcome this, you could implement the DOM heavy business logic into a separate idjs file (having no async/await APIs) and invoke it using app.doScript(idjsFile, id.ScriptLanguage.UXPSCRIPT,
...Copy link to clipboard
Copied
@John D Herzog I don't have full context on this, but I presume that your plugin's inline code calls into InDesign DOM APIs heavily. If this is the case and this code is executing inline within the plugin's business logic, they aren't executed on priority. This could be the reason for the delay you see.
To overcome this, you could implement the DOM heavy business logic into a separate idjs file (having no async/await APIs) and invoke it using app.doScript(idjsFile, id.ScriptLanguage.UXPSCRIPT, args) from the plugin, passing the necessary input as arguments. This will make sure that the business logic is executed on priority and finishes fast. Keep in mind that this block of code is executing in an isolated environment, as any other regular UXP script. UXP scripts with async/await calls are not executed in a run to completion model, as they could be waiting on events for long time, hence you have to make sure not to use async/await APIs in this script's implementation.
Above approach is very similar to CEP, wherein the extendscript executes the script (business logic) in a separate engine. In UXP plugins, we offers the flexibility to call directly into InDesign DOM APIs, but since the plugins are long running and they have to co-exist with other plugins and InDesign's own business logic, on a time shared basis, it isn't possible to run the plugin's inline (InDesign DOM API) code on a run to completion model with priority.
Let me know if this helps.
Copy link to clipboard
Copied
Another option, instead of implementing the idjs script file, could be to pass the script as text to app.doScript from the plugin's business logic. This block of code also executes in a different context, as a standalone UXP script, just like the idjs script file I mentioned previously.
See below.
const {app, ScriptLanguage } = require('indesign');
const args = [100,200];
app.doScript("const script = require('uxp').script;\
console.log(script.args);\
const {app} = require('indesign');\
console.log(app.version);", ScriptLanguage.UXPSCRIPT, args);
Copy link to clipboard
Copied
@Anoop Valomkot The UXP plugin allows to pass functions directly to doScript instead of strings. Can we also expect this to increase speed as well, or does it have to be a string or a file?
import * as InDesign from 'indesign' ;
const { app, ScriptLanguage, UndoModes } = InDesign ;
const scriptProcess = () => {
console.log(app.version) ;
} ;
app.doScript(scriptProcess, ScriptLanguage.UXPSCRIPT, [], UndoModes.ENTIRE_SCRIPT) ;
// --> '18.5.0.57'
Copy link to clipboard
Copied
So the structure is basically the same as a CEP plugin except that you need to doScript instead of evalScript.