SETUP

• IDS Server 14.0.3.433 running on Windows Server 2019 (build 17763.864)




• Local connection using "sampleclient.exe"




• Two test scripts (attached):
  Slow script: "adobe-ids-win-slow.js" (approx 275 KB in size)
  Fast script: "adobe-ids-win-fast.js" (approx 275 KB in size)

PROBLEM

There are two scripts to compare. They are both of identical size, does nothing but declare a variable and return a string value. However, while execution of one of the scripts take a fraction of a second, the other script typically runs for > 10 seconds before completing.

TESTS AND OBSERVATIONS

1) This takes excessive time to run (typically 13 seconds on my test machine):

   C:\Users\Administrator\Desktop>"c:\Program Files\Adobe\Adobe InDesign CC Server 2019\sampleclient.exe" -host localhost:8190 c:\Users\Administrator\Desktop\adobe-ids-win-slow.js

   Script result (std__string): Done

2) This completes quickly (typically in less than 0.1 seconds):

   C:\Users\Administrator\Desktop>"c:\Program Files\Adobe\Adobe InDesign CC Server 2019\sampleclient.exe" -host localhost:8190 c:\Users\Administrator\Desktop\adobe-ids-win-fast.js

   Script result (std__string): Done

3) Adding the "-server" flag to the slow test will make it run fast, since the script isn't passed via SOAP but instead evaluated directly from local disk. This tells me the parsing of the ExtendScript statements isn't slow in itself so the difference seems to lie in the SOAP request handling.

4) Now a really weird part: removing the very first space (before the comment on line 1) in "adobe-ids-win-slow.js" makes it run almost as fast as the fast script when repeating test 1) above. It turns out that "adobe-ids-win-slow.js" MUST start with a / /-style comment in the very first byte to run fast; adding the space back, or removing the comment completely, makes it evaluate slowly again. I've tried other tokens such as semicolon, //-style comment, curly brackets etc but none had the same effect.

5) In contrast to the change in 4), adding spaces before the comment, or removing the comment entirely, from "adobe-ids-win-fast.js" makes no difference in its evaluation performance.

6) Another strange discrepancy is that even when "adobe-ids-win-slow.js" is modified to run fast using the change described in 4) above, the speed is still slower than the "adobe-ids-win-fast.js" variant. They both declare a string of same length but the data INSIDE the string is different, but while "adobe-ids-win-fast.js" completes in < 0.1 seconds the modified "adobe-ids-win-slow.js" takes closer to a full second.

7) All of the tests above run at good speed (less than a second) when connecting to IDS 14.0.2.324 on macOS (tested with Catalina 10.15.7). The minor difference in speed between the slow and fast scripts seen in 6) is still present though, but is again eliminated if the "-server" option is used.

OTHER COMMENTS

I tried running Microsoft's Windows Performance Analyzer to capture what the slow IDS is doing during the long wait. I found that the overhead is located in calls from AFL (Adobe File Library) to the NT kernel, but without debug symbols I couldn't pinpoint it in more detail. My totally unconfirmed suspicion is that gSOAP/2.7 (as returned in the "Server" HTTP header in IDS connections) is applying some content sniffing to detect encoding, data format or other properties of the inlined script, but why this would only take place on Windows is a mystery, and it's also odd that the initial code comment would short-circuit this and improve performance dramatically.

I've also tried disabling various Windows Security settings (Firewall, Virus & Threat Protection, Exploit Protection etc) in case that was interfering with network I/O but I've not found any improvement in that area.

The slowness is not inherent in "sampleclient.exe" either since the root problem was first observed using our own HTTP client, as was the weird workaround of adding the comment string. I'm just using "sampleclient.exe" here to set up a self-contained test case.

The attached IDML test case (also applicable to CC15/18 clients) enters an infinite recompose loop directly after opening. The second text column repaints continuously. This in itself doesn't directly block interactive use of the InDesign client since recomposing is a background task, but as soon as one tries to save/export the document to disk the application hangs (most likely waiting for a stable document state).

It's notable that the exact placement of the small text frames containing arrows are a necessary piece of the puzzle. Moving them outside of the main text column stops the recompose loop, but then moving them back to their original position will bring back the problem.

Our use case of opening/processing/saving this document (or rather more complex variants of it) on InDesign Server is therefore entering a state where IDS consumes 100% CPU and never completes the action, thus creating a serious disruption in the workflow.

I have not been able to reproduce the problem with CC19 (I tested 14.0.2.324), but CC15 (11.4.1.102 and .105) as well as CC18 (13.1.0.76) all show the same behavior. I'm using macOS 10.14.3 and our IDS runs on various older macOS installations (10.11.6 is one of them).

I'd be thankful for some input on the following questions:

– Is CC19 fixing this problem by design or am I just lucky to not trigger a similar bug there for now (i.e. the potential risk remains)?

– Any chance of a fix be distributed for CC18 or CC15 in future Rapid Release builds?

– Are there any preconditions in the document that we can change to avoid the buggy code path altogether? E.g. any frame/style/document property that we can instruct our customers to avoid and thereby be safe?

Don't hesitate to ask for more details if needed.