5 Replies Latest reply on Jul 31, 2012 12:40 PM by Dirk Becker 

    Problem with InDesign server - Server slows down fast

    Dmitry Aleksandrov

      My javascript code iterates the pages of the InDesign Document and searches for the text frames with some special character style.

      I found some samples from Jongware :

       

      sourcelist = app.activeDocument.findText()

       

      and

       

      sourcelist = app.activeDocument.pages[p].textFrames[f].findText();

       

      if I use the first variant the memory goes to ca. 1.2GB (the server has 4GB), the search is completed in ca. 2 minutes but InDesign Server works incredibly slow.

      The problem is I have to find a page for each text found.

       

      If I use second variant the memory goes high slowly and so each iteration needs more time.

      After 300th page InDesign Server needs up to 30-40 seconds to process the page.

      (First pages are processed 3-4 per second)

       

      I tried several possible implementations, like

       

      for each page

           var actualPage = pages[i]

           for each frame

                var actualFrame = frames[i]

                var sourceList = searchText(actualFrame)

                     parseText(sourceList)

       

      or

       

      var actualPage=null,  actualFrame = null, sourceList = null;

      for each page

           actualPage = pages[i]

           for each frame

                actualFrame = frames[i]

                sourceList = searchText(actualFrame)

                     parseText(sourceList)

       

      I've tried functions with local variables. Nothing changes.

       

      Processing of the first 50 pages is really fast, but the test document has 630 pages.

      And I have no ideas how to make InDesign continue to work fast.

       

      Have someone had similar problem? Any ideas?

        • 1. Re: Problem with InDesign server - Server slows down fast
          Dirk Becker Level 4

          I'm not sure how app.activeDocument works on your server at all - at least with my working horse InDesign CS4 "activeDocument" was a non-Server feature.

           

          As far I know, Text objects (Paragraphs, Words, and so forth, all your text findings) are not bound to a real object so a new instance is produced on every access of a parent collection, search etc. For Text these "Proxy" objects can become very fat, internally they are so-called "Suites". Apparently there is no way for the ExtendScript engine to tell that all references have expired thru garbage collection so these objects fill up a temporary manager until the document is close()d. An occasional save() could also be sufficient.

           

          One approach: do your processing in multiple steps, closing and re-opening every now and then (e.g. your 50 pages). Remember the found pages separately, in some notation that is not dependent on the document as the document object can be different after re-open - that change was introduced by CS5. For example just store the myPage.id and use myDocument.pages.itemByID() to recover the page for the final processing.

           

          Dirk

          1 person found this helpful
          • 2. Re: Problem with InDesign server - Server slows down fast
            Dirk Becker Level 4

            You could also give the following expression a try:

             

            var findings = new Array().concat.apply([],myPage.textFrames.everyItem().findText());

             

            Dirk

            • 3. Re: Problem with InDesign server - Server slows down fast
              hugli2

              I have similar (and unsolved) issue here as well. Document is a product catalogue. afterOpen event triggers this pseudo code:

              #targetengine "session"
              #include Product.jsx
              # doc parsed from event object

              product_boxes =  doc.groups.items_with_label('product')
              doc.products = {}

              for box in product_boxes:
                  product = Product(box)    # parses InDesign group into javascript object
                  doc.products[product.code] = product

              My intention is to have in-memory parsed dictionary of product objects with methods and attributes that allow me to manipulate them without accessing low level InDesign DOM. It works nicely for smaller catalogue sections. The parsing loop above takes (acceptable )2-5 seconds for 50 products (Represented by groups in document). One would expect 8-20 seconds for 200 products. But the parsing time seems to grow exponentially instead of linearly for no reason. Anyone can accept +5 seconds with their initial 20 seconds opening time for document. No one is extatic about +5-10 minutes.

               

              In my case there's no memory hog. Only the decrease of speed (quite frustrating, considering there are 7 unused cpu cores)

              CS5, OSX 10.6.minor_something

              • 4. Re: Problem with InDesign server - Server slows down fast
                Dmitry Aleksandrov Level 1

                Thank you, Dirk.

                 

                That was the next thing I wanted to try and it really works.

                Now I close document after 100 pages and reopen it.

                Pages are processed with normal speed.

                 

                I have not got your notation on pages though.

                When I iterate through the pages from first to last, it seems they are always in the same order,

                but I will keep your note in mind.

                 

                PS: app.activeDocument does not work on my server   just have copied it from source that way.

                • 5. Re: Problem with InDesign server - Server slows down fast
                  Dirk Becker  Level 4

                  To clarify my comment on pages:

                   

                  JavaScript objects referencing a native InDesign object have an internal representation for their "address" in the DOM, a textual form (similar to an XPath) is available via toSpecifier(). The specifier starts at the document and then follows collections (e.g. pages) and collection accessors (e.g. itemByID()) to finally reach the same object.

                   

                  You can see that the specifier of the document before and after the close/open roundtrip changes in CS5 or later (different document ID), where CS4 used a different specifier form (itemByName() for the document) . The renumbered document ID renders previous references to the same page invalid - see the isValid property. If you want to revive such a stale object reference across close/open, you can remember the page ID and use your reopened document's myDoc.pages.itemByID() method to get to the same object.

                   

                  Regarding your other performance problem: print the output of the ExtendScript helper function "$.summary()" before and after the code sequence in question, or compute the differences. You may want to precede that with two explicit calls for the garbage collection "$.gc()" - yes, double invokation seems to be more thorough. Sometimes you find memory leaks that way, for example caused by the javascript "closure" design pattern (all those "Workspace" objects).

                   

                  Dirk