[JS] How to speed up file operations in InDesign script?

[JO_15]

The script I have on my computer takes around 6 minutes to run. I used $.hiresTimer to measure the time that each line of code takes to run. It turns out the file operations are taking the bulk of my time in my script.

For example this line of code:

var titlePage = app.open(file, Boolean.false, OpenOptions.OPEN_COPY);

takes 3 seconds to execute.

Here I save the file and it takes 5 seconds to execute:

titlePage.save(file, Boolean.false, "saved", Boolean.true);

The file only has 5 pages and is 8,284 KB in size.

Lastly I close the file and it takes 1.5 seconds to execute.

titlePage.close(SaveOptions.YES);

My system has SSD drives and I have not noticed any file performance issues. My script does these open/save/close operations 52 times.

If anyone has any tips on how to improve the above file operations I would be very appreciative. Saving a even a half second per file operation could make a big difference to the overall script running time.

Thank you in advance for any help provided!

[JO_15 · Accepted solution]

[Update]: 

So I tried calling my script via app.doScript and it significantly sped it up. Here is the call I used:

app.doScript ( f1, ScriptLanguage.JAVASCRIPT, Undefined ,UndoModes.FAST_ENTIRE_SCRIPT, "ScriptRun" );

With this change my entire script is running in two minute and 25 seconds as opposed to six minutes.

The main areas sped up with the open and the close operations. They went from 3 seconds to 0.3 seconds, and from 1.5 seconds to 0.18 seconds.

The save still takes some time at 3 seconds but it is an improvement over the previous time it took of 5 seconds.

[m1b]

Cool! Long shot, but are you able to close and save the document in the one .close() operation?

[JO_15]

That is one thing I am considering since the file operations take so long. I am glad I discovered the HiResTimer. It has really helped me evaluate how to speed up my script.

[m1b]

Nice one. Performance is something I occasionally would like to improve in my own scripts but rarely know how.

[JO_15]

I have found using the $.hiresTimer very valuable for evaluating what parts of the script are taking the most time. 

I will use something like this:

$.writeln("Reset Timer: " + ($.hiresTimer / 1000000));
docFile = app.open(file, Boolean.false, OpenOptions.OPEN_ORIGINAL);
$.writeln("File Open: " + ($.hiresTimer / 1000000));

Each time you call $.hiresTimer it shows the time since $.hiresTimer was last called and then resets it. The time is output in microseconds. I divide it by 1000000 to view the time in seconds which is easier to understand. Hope that helps!

[JO_15 · Accepted solution]

[Update#2]:

I have been building a new box with a Ryzen 5950X, 64GB ram, and a 980Pro SSD. My first initial tests on that box showed even slower speeds then my current box even with the app.doScript call!

So after a lot of debugging I think I traced down some potential causes.

- The files were being opened over the network. I moved the files to the local drive.

- I had preflight turned off to save performance. That caused me to miss that some fonts were missing and links to images were broken. I made sure the box had the appropriate fonts.
- I exported the local files as .IDML files and then resaved them locally as .INDD files.

After the above changes I turned on preflight to make sure each file had no errors and then turned preflight back off.
With the above changes the script on the new box runs even faster then my old box. The script is running at 1 minute now instead of two minutes 25 secconds. My old box is a 32GB ram, Core i7 6700k, and a 850 Evo SSD.

I suspect that the open and saves were hanging on the missing fonts, and or old links to the images on the network.

I still plan on potentially trying some of the solutions others have suggested below and see if I can make the script faster.

[Manan Joshi]

Hi @JO_15,

My thoughts which you could investigate are listed below.

• Evaluate and probably optimise the open/save/close operations. You say you do these operations some 52 times, if you could relook and reduce this number it would help. So if we think, once you do the open/save thing can't you keep the document open instead of closing it and then opening it again after sometime
• Another option could be to open the document without a UI window, this would reduce the UI refresh operations and the other parts of the script execution might be sped up
• Next you could export the document to IDML and resave it as INDD to increase the chances of document corruption if any being corrected out.

-Manan

[Laubender]

Manan said:

"Next you could export the document to IDML and resave it as INDD to increase the chances of document corruption if any being corrected out."

Hi Manan,

I would not recommend that IDML workflow. Two things that speak against it:

[1] It takes extra time to build an InDesign document from an IDML file.

Depending on the contents it could take a lot of time.

[2] INDD > IDML > INDD unfortunately is not 100% perfect; it highly depends on the contents of the INDD document. In some cases contents will miss, because IDML lacks properties. In other cases the result will look different, because of special circumstances.

The OP JoJa15 says: "My script does these open/save/close operations 52 times."

Is this the same document? If yes, why do you have to do that?

Regards,
Uwe Laubender

( ACP )

[Manan Joshi]

Hi @Laubender,

I suggested the IDML->INDD workflow for a case where the InDesign file has been corrupted somehow. In such a case what other alternative would we have?

Also I meant this to be done once not everytime during the workflow, supposing that the file originated in the same version of InDesign and would be processed on the same version.

I myself am not sure and did point on the very high, 52 times execution of save/close/open operations in the OP's workflow, that is something I would have looked at first of all as you also pointed.

-Manan

[JO_15]

Thank you for the information. I need to check my final compiled document (it is 500 pages) becuase I tried the INDD>IDML>INDD process.

[Peter Kahrel · Accepted solution]

Opening an InDesign document involves two things: opening the file and displaying it. The first step is quick; the second step takes time. So because In scripts you usually don't need to see the contents, open the file without displaying it:

app.open (f, false);

This alone speeds up a script enormously when it processes a lot of files.

Your code to save and close a file does more than necessary. When you save it, then there's no need to save it when you close it:

titlePage.save(file, Boolean.false, "saved", Boolean.true);
titlePage.close(SaveOptions.NO);

Maybe your last parameter, to forcesave a file, adds time. I never use it and have never had a problem saving a file. Try your timer on that parameter.

P.

[JO_15]

Hi Peter,

This is what I am using for my open:

var titlePage = app.open(file, Boolean.false, OpenOptions.OPEN_COPY);

That should be the same as what you are suggesting right? The weird this is even though I have the second option set to false I still see the file open in InDesign.

I actually tried commenting out the save line because I felt that if the close statement has a forced save I did not need to do the initial save. When I tried that though it errored on the close statement. I forget what the error was though unfortunately. I will try your suggestion and change the SaveOptions to NO.

Check out my Update#2 post (which I will post after this reply) for more information on the source of the performance issues.