How big a script is too big for debugging?

[Karl Heinz Kremer]

I have a rather large InDesign scripting project with one main .jsx file which includes a bunch of other files, just to keep the file contents somehow managable. The script produces PDF output based on XML input. The document structure varies, so there is quite a bit of logic in the script to place tables, EPS graphics, and text in a way that complies with the design rules. There are different document types that get processed, and every document type has it's own set of files (it's a standalone scripting project with it's own main and include files). 

When I try to debug these projects, some let me step through the code, set breakpoints and all the things that are necessary to find and fix bugs. There are however a couple projects where I cannot step through the code: When the program reaches a breakpoint, it is very sluggish, and it may take e.g. 10 minutes for it to execute the next line, but most of the time it will just sit there indefinitely, showing "Not reposning" in the ExtendScript Toolkit window title, and eventually dims the whole window. 

I assume that the difference between working and not working is the complexity of the project. I've tried different versions of ExtendScript Toolkit, with the same results. This is happening on a Windows 10 system with InDesign CC 2018, but earlier versions showed the same behavior. 

Is there anything I can do to make this work (better)? 

Unfortunately, I cannot share the code. 

Thanks, 

Karl Heinz 

[Karl Heinz Kremer]

Forgot to mention one other symptom: After I let the Toolkit app site for a while, it oftentimes changes the size of the window and turns the content black - without a title bar anymore:

 

[Dirk Becker]

My largest project back with CS4, Mac, ID + IDS, was close to 200k lines. Back then we had no trouble with the debugger itself, but the ESTK profiler was overwhelmed and just would show nothing so I wrote my own.

Your problem sounds more like InDesign itself or its scripting engine are busy with some lengthy task so that BridgeTalk debug messages are not handled in time. Of course this could be everything, including gathering data for a too large debug browser hierarchy, garbage collection at the ES side or low memory situations within InDesign.

As you tagged the thread with "SDK": Instead of guessing I'd use a debug build of InDesign (download from prerelease program), ITK and look from a plugin-level debugger (Xcode or VisualStudio) where it is stuck.

For the fun of it I'd also try the other platform (Mac vs. Windows), plus VS Code for ExtendScript debugging. If I still had such a large scripting project, I'd anyway move it to something more modern than ExtendScript, e.g. Java or TypeScript/V8. That's beyond the scope of your question though. How about writing a good old log file, print statements to nail down the offending source area?

Regards,

Dirk

[Karl Heinz Kremer]

Dirk, thanks for chiming in. I have two projects that are very close in size (based on number of lines, one is 11189 and works, the other one is 11792 and does not work). As far as I can tell, the complexity is very similar as well, and what InDesign does is also very similar. So I am still scratching my head as to the debugger works for one, but not the other. The log file approach is exactly what I am doing. I just dump out a whole bunch of data. The only problem with this is that it takes about 15 minutes to create the document, so if I change my mind while the program is running about what kind of data I am interested in, I have to start from scratch and cannot just inspect another variable 🙂

Thanks again. 

[Harbs.]

From my experience, the size of the script is not the concern. I have quite a lot of code loaded into memory.

[Harbs.]

Ugh. These new forums post when you type a line return. How dumb is that?

[Harbs.]

I figure a soft return would at least work, but apparently not. Not sure how to type multiple paragraphs. Here's my pointers:

[Harbs.]

1. For code that's run a lot, load it into memory using a persistent engine and only redeclare functions when there's a reason to.

[Harbs.]

2. Some things cause memory consumption of InDesign to go quite high. One common example is opening and closing a lot of documents. Depending on the circumstances, the memory might not be freed until the script finishes. For cases where this is a problem, you should use an async loop using IDLE events or CSEvents instead of a hard sync loop. That allows memory to be freed between iterations.

[Karl Heinz Kremer]

You are right, the forum behavior is very annoying. Thanks for the information about using IDLE events/CSEvents. I will look into that.

[Test Screen Name]

I find this (posting on return) annoying. Also the one line box. The solution seems to be to use the FIRST Reply button, which has different magic.