Issues with Mutlithreading and STA [modified]
-
I am currently working on an app that requires large volumes of processing. The long story short, it was determined that threads would be the best way to split it up and increase performance of the application. Heres the catch: I have to use STA as the com objects used are registered as STA objects. Fun! I ran a quick test with one STA/thread and two STA/threads both running the same code and the results show that the single thread was actually faster than using two threads. I figure this is due to the nature of the message queue and sequential processing. So my question is this, is there any way to have an STA that can process simultaneously without a performance decrease? My code is fairly simple:
ParameterizedThreadStart workerThread = new ParameterizedThreadStart(EditFeatureClass); Thread protoThread = new Thread(new ThreadStart(ItterateFeatureClass)); protoThread = new Thread(workerThread); protoThread.SetApartmentState(ApartmentState.STA); protoThread.Name = featureName; protoThread.Priority = ThreadPriority.Highest; protoThread.IsBackground = true; protoThread.Start((object)featureName); }Any suggestions and comments would be appreciated (And no, I am stuck with STA). I have posted a copy of the unedited document I have been working on in regards to this if it helps. It should be the second link - Thread Performance Testing.[^] -- modified at 18:25 Thursday 4th October, 2007_____________________________________________________________________ Our developers never release code. Rather, it tends to escape, pillaging the countryside all around. The Enlightenment Project (paraphrased comment) Visit Me at GISDevCafe
-
I am currently working on an app that requires large volumes of processing. The long story short, it was determined that threads would be the best way to split it up and increase performance of the application. Heres the catch: I have to use STA as the com objects used are registered as STA objects. Fun! I ran a quick test with one STA/thread and two STA/threads both running the same code and the results show that the single thread was actually faster than using two threads. I figure this is due to the nature of the message queue and sequential processing. So my question is this, is there any way to have an STA that can process simultaneously without a performance decrease? My code is fairly simple:
ParameterizedThreadStart workerThread = new ParameterizedThreadStart(EditFeatureClass); Thread protoThread = new Thread(new ThreadStart(ItterateFeatureClass)); protoThread = new Thread(workerThread); protoThread.SetApartmentState(ApartmentState.STA); protoThread.Name = featureName; protoThread.Priority = ThreadPriority.Highest; protoThread.IsBackground = true; protoThread.Start((object)featureName); }Any suggestions and comments would be appreciated (And no, I am stuck with STA). I have posted a copy of the unedited document I have been working on in regards to this if it helps. It should be the second link - Thread Performance Testing.[^] -- modified at 18:25 Thursday 4th October, 2007_____________________________________________________________________ Our developers never release code. Rather, it tends to escape, pillaging the countryside all around. The Enlightenment Project (paraphrased comment) Visit Me at GISDevCafe
-
Aaron VanWieren wrote:
it was determined
what do you mean "determined"? Does that mean "assumed"? I suggest Advanced Windows by Richter, it might be able to shine some light on your subject.
It was the direction my boss said to go. Read some Richter, will look into that one.
_____________________________________________________________________ Our developers never release code. Rather, it tends to escape, pillaging the countryside all around. The Enlightenment Project (paraphrased comment) Visit Me at GISDevCafe
-
I am currently working on an app that requires large volumes of processing. The long story short, it was determined that threads would be the best way to split it up and increase performance of the application. Heres the catch: I have to use STA as the com objects used are registered as STA objects. Fun! I ran a quick test with one STA/thread and two STA/threads both running the same code and the results show that the single thread was actually faster than using two threads. I figure this is due to the nature of the message queue and sequential processing. So my question is this, is there any way to have an STA that can process simultaneously without a performance decrease? My code is fairly simple:
ParameterizedThreadStart workerThread = new ParameterizedThreadStart(EditFeatureClass); Thread protoThread = new Thread(new ThreadStart(ItterateFeatureClass)); protoThread = new Thread(workerThread); protoThread.SetApartmentState(ApartmentState.STA); protoThread.Name = featureName; protoThread.Priority = ThreadPriority.Highest; protoThread.IsBackground = true; protoThread.Start((object)featureName); }Any suggestions and comments would be appreciated (And no, I am stuck with STA). I have posted a copy of the unedited document I have been working on in regards to this if it helps. It should be the second link - Thread Performance Testing.[^] -- modified at 18:25 Thursday 4th October, 2007_____________________________________________________________________ Our developers never release code. Rather, it tends to escape, pillaging the countryside all around. The Enlightenment Project (paraphrased comment) Visit Me at GISDevCafe
Hi, you did not tell us much about ItterateFeatureClass. If all it does is call your COM object, I am afraid the only way to get it really multi-threading is by providing multiple identical COM objects, one per thread, assuming the functionality allows that. The alternative of course would be putting the multithreading right inside the COM object itself, but I guess that is not what you hope for. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - use PRE tags to preserve formatting when showing multi-line code snippets - before you ask a question here, search CodeProject, then Google
-
Hi, you did not tell us much about ItterateFeatureClass. If all it does is call your COM object, I am afraid the only way to get it really multi-threading is by providing multiple identical COM objects, one per thread, assuming the functionality allows that. The alternative of course would be putting the multithreading right inside the COM object itself, but I guess that is not what you hope for. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - use PRE tags to preserve formatting when showing multi-line code snippets - before you ask a question here, search CodeProject, then Google
IterateFeatureClass() is just a test class for right now that performs a number of editing operations, which are set up through the COM objects. I would have included that code but it includes allot of third party library stuff that is registered as STA. I ran a test with two threads and my time doubled compared to my single thread test. I made sure to time the performance for just the iterations as well as the setup and tear down. Basically my test code is creating a workspace(think database connection) and retrieving a featureclass(think table). From this feature class it creates an object and adds a feature(think row) then modifies a field(think column) and finally it stores it in the workspace. I am trying to explain this without getting too much into the library as it is different terminology. But I have ensured that all the COM Components are generated withing the STA thread.
Luc Pattyn wrote:
The alternative of course would be putting the multithreading right inside the COM object itself, but I guess that is not what you hope for.
As this is a library I cannot modify I cannot do this. The interesting this is that a colleague of mine attempted this and just through it together with MTA threads. In my testing I discovered this was the worst thing to do performance wise as it took the MTA thread 8 mins to do what an STA thread was doing in 4! Hope this helped a little bit more.
_____________________________________________________________________ Our developers never release code. Rather, it tends to escape, pillaging the countryside all around. The Enlightenment Project (paraphrased comment) Visit Me at GISDevCafe
-
IterateFeatureClass() is just a test class for right now that performs a number of editing operations, which are set up through the COM objects. I would have included that code but it includes allot of third party library stuff that is registered as STA. I ran a test with two threads and my time doubled compared to my single thread test. I made sure to time the performance for just the iterations as well as the setup and tear down. Basically my test code is creating a workspace(think database connection) and retrieving a featureclass(think table). From this feature class it creates an object and adds a feature(think row) then modifies a field(think column) and finally it stores it in the workspace. I am trying to explain this without getting too much into the library as it is different terminology. But I have ensured that all the COM Components are generated withing the STA thread.
Luc Pattyn wrote:
The alternative of course would be putting the multithreading right inside the COM object itself, but I guess that is not what you hope for.
As this is a library I cannot modify I cannot do this. The interesting this is that a colleague of mine attempted this and just through it together with MTA threads. In my testing I discovered this was the worst thing to do performance wise as it took the MTA thread 8 mins to do what an STA thread was doing in 4! Hope this helped a little bit more.
_____________________________________________________________________ Our developers never release code. Rather, it tends to escape, pillaging the countryside all around. The Enlightenment Project (paraphrased comment) Visit Me at GISDevCafe
Hi Aaron, if your CPU load is sufficiently low right now on both client and server (assuming DB on separate machine here), the only thing I can think of that could improve overall elapsed time is using multiple processes, each with one STA thread, again assuming the job can be split in independent parts, that just share data at the database level. This would basically cost additional CPU cycles to perform the remoting, but it would increase parallelism on the DB operations. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - use PRE tags to preserve formatting when showing multi-line code snippets - before you ask a question here, search CodeProject, then Google