I'm currently working on an Add-in for ArcMap 10.0. As part of this, I need to interrogate a geodatabase containing point feature classes, to see which of these points lie within an input polygon, and sum various attributes associated these relevant points. As the geodatabase is very large, this can take a fair while (~few minutes).
Obviously making ArcMap hang while this calculation is taking place is not ideal, so I'd like to have the geodatabase access & interrogation take place in a background thread. Unfortunately, this seems to increase the calculation time by a factor of ~5-10 - seemingly because all the calls to COM components are getting held up somewhere. I've tried a number of methods to speed things up, but with no success (BackgroundWorkers, Threads with the STAThread attribute, Control.BeginInvoke methods...); with the exact same code, it takes several times longer in a background/non-UI thread.
Does anyone have any advice on how to make ArcObjects access work with any degree of speed when not run in the UI thread? Any insight would be much appreciated; I have run out of ideas!
One option would be to refactor your geodatabase query logic into a Custom Geoprocessing Function Tool.
This would enable you to execute the logic in a separate/background thread while still retaining the necessary performance.
Erin - thanks for the info; I'll have a look into the geoprocessing option next time I get a chance.
Javier - thanks for the reference; I have read through that, and the STA threading methods it explains still seem very slow compared to single-threaded... I'll read through it more thoroughly though and see if there's anything I haven't tried.
I can give you only one advice then: Just make sure that there are no shared ArcObjects objects across the threads.
Ideally you should pass a string with the path of the workspace and create all the necessary objects inside the thread.
For further info, when I've dealt with threading and ArcObjects, i've used System.Threading.Thread in STA apartment state.