2 Replies Latest reply on Apr 18, 2012 12:34 PM by Ed Little

    ScriptingBridge Memory Consumption

    Ed Little

      I have an application that needs to interact with InDesign from multiple threads.  I'm using ScriptingBridge to send Apple Events to InDesign, using a static instance of NSLock so that although the application is multi-threaded, InDesign is only responding to one AppleEvent from my application at a time.  The application performs as expected, but the memory footprint is quite high--well into the hundreds of megabytes on top of the two hundred or so megabytes that InDesign is already consuming.

       

      The following code snippet illustrates the point.  If you run the following code in an application and watch the Real Memory column of the Activity Monitor, you will see the memory footprint rapidly climb.  I've tried running this code against the Leaks Instrument, but there are so many allocations that Leaks gets overwhelmed. 

       

       

      #import <ScriptingBridge/ScriptingBridge.h>

      #import "Adobe InDesign CS5.h"

       

      /***************************************************/

       

      - (void)instanceUpInDesignApp {

        NSAutoreleasePool *localPool                                        = [[NSAutoreleasePool alloc] init];

        AdobeInDesignCS5Application *theApp                              = [SBApplication applicationWithBundleIdentifier: @"com.Adobe.InDesign"];

                [localPool drain];

      }

       

       

      Is this a known issue in InDesign?  Is there anything I should do differently in my application code?  Is there a "lightweight" subclass of SBApplication for InDesign, or a way of creating a "lightweight" subclass with only the limited functionality that my application needs?