|
I am testing code that uses backgroundWorker. A similar application run on a different computer runs code that is practically the same, and is faster, but doesn't use backgroundWorker. Could the backgroundWorker be taking longer than code that doesn't use the backgroundWorker? Other differences are 32 bit vs 64 bit(mine)computer. My code also uses more dll's, but using a profiler with my code, the part that was taking long was a repeated call to an external dll, which the other code also does.
|
|
|
|
|
The answer is that you aren't comparing the same thing here. What BackgroundWorker does is allow your code to run asynchronously, which simplistically means that the computer will allocate time to run the code on a different thread. This means that there is no guarantee when the code in the async side runs - or completes.
When you run the code on the primary thread, then all the time that your program is running this section of code is allocated to it (assuming you haven't created any other threads), but you will block the primary thread here. I would suggest that you have a read about threading, and investigate the Task classes that make asynchronous code a lot easier.
|
|
|
|
|
It looks like I had this question post twice. I put a response on the other one. That would be great if we could switch the primary discussion to the other posting. Thanks!
|
|
|
|
|
Maybe the problem is with how I create the backgroundWorker. From my form class, I am doing the following (I create two of these..one for each form tab):
if (!backgroundWorker1.IsBusy)
{
try
{
backgroundWorker1.RunWorkerAsync();
}
}
Is there a way I can still have the user able to hit a button on the form, yet have the backgroundWorkers hog more of the processor so they can have priority over the form and other things on the computer?
|
|
|
|
|
Not with a background worker - the whole point is that it's meant to work in the background. If it has a higher priority, then this would slow down your application and will lead to a poor user experience.
|
|
|
|