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

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

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