my apologies if anyone has asked this question… and I’m sure they have…
I work with InDesign Documents of over 2000 pages per document, and scripting InDesign to automate production… My only concern is Applescript’s inherent overheads… namely processing speed… normally this is not a problem… though I need to make commercially viable scripts (that operate within short deadlines)…
I’m considering rewriting / moving all my scripts into Applescript Studio and making ‘Cocoa’ (?) Applications from them… hoping to speed up processing. Simply saving a script from ScriptDebugger as an application causes a major slowdown in script operation compared to just running the same compiled script directly in Script Debugger…
Having no experience of Applescript Studio or C programming… I was hoping that soembody could give me a definitive answer as to what is the fastest execution method I can use when writing ‘Applescript only’ code…
I don’t think you’re going to find a lot of difference between a compiled app in Script Debugger and a compiled AppleScript Studio app - they both essentially work the same way.
Instead, you may find that your best optimization comes in analyzing the code - looking at your loops and, especially, your lists (lists can be very inefficient depending on their size and how you build them).
I don’t know the full details, but this is something to do with the communication time between applications: the script applet and InDesign in your case. The applet only issues the next command from the script when it receives confirmation that the previous one has been carried out. It’s the time taken for each command to reach InDesign and for each of InDesign’s acknowledgements to get back to the applet that slows down the execution of the script as a whole. For some reason, there’s usually no problem if the script’s run as a compiled script in a script editor or from Script Menu. And there’s no problem with a script applet if no other application’s involved.
If it’s possible to give InDesign commands to do things in bulk, as it is with the Finder, that might be one way to go.
Another thing that often seems to work is to make use of the fact that the communication time between OSAXen and applications is much less than that between applications. If you put script code in a script object and use the StandardAdditions run script command to execute it, the “handshake” traffic will be between the StandardAdditions and the applications rather than between the applications directly:
(* Applet code. *)
script myScript
-- Your script code here, including commands to another app.
end script
-- Tell the StandardAdditions to run the above script code on behalf of this applet.
run script myScript
Try saving the script as a compiled script and running it through InDesign’s script menu. I seem to remember that this does speed things up marginally, particularly on launching the script.
Next review your code and see if there are any duplicate calls to the program. I’ve seen, and written code that goes to the app for one thing, say for the bounds to check the width, then a bit later goes to it again and gets the bounds again to alter them in some way and finally applies them to the object. Reduce as much of this as possible by saving them in variables to work with.
Another thing that slows down ID scripting is updating the screen. You can open a document without showing the window, then later when you are done show it so the user has it available in necessary. You cannot hide the window once the document is open though so this might not be an option for your scripts. You might also speed things up by hiding the pallets (From the folks at Scripting Matters http://scriptingmatters.com/indesigncs_changes.php )
tell application "InDesign CS"
set theDoc to open filePath without showing window
-- do a lot of stuff
make window at theDoc
end tell
tell application "InDesign CS"
set palettes visible to false
end tell
If you need to go further than this then get the InDesign SDK for Adobe and spend the time to convert it into a plug-in which will probably give you the most integration and best performance.