|
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.
|
|
|
|
|
If it's done wrong, sure. Plus multi-threading adds more complexity which can mean things like checking a semaphore and locking. This could lead to lessened performance, but that could just mean that the problem isn't suited to multi-threading.
We'd need to see the code to be sure.
|
|
|
|
|
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?
|
|
|
|
|
I just use Threads, not BackgroundWorkers, and I always set them for lower Priority.
|
|
|
|