I have created a class library which does some geoprocessing. The addin calls a class that is an async process. I have ensured the thread is STA and the arcobjects are thread safe (ie. not passed from the addin). All arcobjects are created within the thread.

Because this is a class library I wrapped it in a winforms UI and also as an addin. Both sets of code are exactly the same and test were performed using the exact same data. Both the winforms and addin complete the code with the desired results and no memory leaks are evident. For the case of the addin there is no interaction with the map period at this point and there are no mapping or display elements in the winforms code either.

the only UI updates are the update of a progress dialog in both the addin and UI. The addin is using a dockable window (user control ui).

The issue I am seeing is when the library is called from the addin, code execution is 5x slower than the same code called through the winforms application.

Any ideas on where I might look to see why this is occurring?

  • Are you using any arcobjects singletons? Mar 18, 2013 at 15:35
  • Yes, a quick look at the list and I am using a few workspacefactory objects to open my featureclasses independant of ArcMap so they are created within the thread. I am creating two workspacefactories (for my input and output) then looping and caching data locally using an inmemmoryworkspace which I use a factory to create. Should I create the inmemoryworkspacefactory only once? I should mention the code doesn't fail and is slow only when executed within the addin. Mar 18, 2013 at 15:47
  • Are you creating using Activator.CreateInstance, or with new ? Mar 18, 2013 at 15:51
  • I am (or was) using the new. I am updating now to try the Activator.CreateInstance method. Mar 18, 2013 at 15:55
  • I updated the code (thanks for pointing that out) but don't see a real difference with the update. Mar 18, 2013 at 17:25

1 Answer 1


When comparing both versions, you may be timing more than just the geoprocessing time.

Perhaps there are some initialization procedures running in your standalone application that are already performed in ArcMap at startup e.g. creation of MxDocument object, license checkout, creation of scratch GDB, etc.

There could also be a difference in the .NET Framework version used in ArcMap and your desktop application (Although I don't see that causing a 5x slowdown).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.