Problem with InDesign server - Server slows down fast

Question

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?

Answer 1

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