CODEWITHSUNDEEP
c#winformsmultithreadingbackgroundworker
RedPanda
RedPanda

Reputation: 135

Background Worker C# winform

is it a bad idea to load everything in from the background worker?? Current code is Executed on Form_load. we are pulling a lot of data from webservice. some long running works are in background worker.

would it be a bad idea to load everything from background worker no matter how small or big the code is?? every function to run in background worker? or is this going to make this code messy and treading nightmare.

Thank you.

Upvotes: 6

Views: 2323

Answers (7)

hemp
hemp

Reputation: 5683

The size of the code is not a metric you should use to determine whether to perform work on a separate thread. Worst case length of execution is.

First, there aren't many UI designs where firing off a bunch of work on Form_Load is really desirable. If it's possible, I typically either:

  • Initiate that work prior to opening the form directly in response to a user action.
  • Move all of the work into the background and asynchronously update (bind?) the results to the form.
  • Delay the work until the user specifically performs some action which requires it.

Your users will want/expect your forms to be extremely fast and responsive regardless of how much work is being done. Executing potentially long-running operations during Form_Load is always going to result in a bad user experience.

BackgroundWorker is only one mechanism for performing work asynchronously, there are many others. You should choose the one that is most appropriate for each situation.

Upvotes: 2

Paul Keister
Paul Keister

Reputation: 13097

Personally, I wouldn't put code into a worker thread unless the code comprised a specific process was interfering with UI responsiveness. There's no reason I can think put everything on a worker thread. Generally you only have responsiveness issues when you're waiting for an external resource like a web service (unless you are calculating prime numbers on Form_Load :-).

If you haven't explored asynchronous web service calls, I would recommend taking a look. The asynchronous calls will handle your threading for you - always a good thing.

Upvotes: 1

µBio
µBio

Reputation: 10758

Whether it is a good idea or not depends very much on the specifics of your problem. Do you have to pull all the data in one call or can you do it in independent chunks?

If it is one big long running web service call, then putting it on a thread won't do anything for you. Your best case would be several independent, long running chunks that take approximately the same amount of time to return.

Also, in webforms (since you mention Page_Load) IIRC you will be sharing the thread pool with asp.net, and you may cause your app to become less responsive overall at some threshold of concurrent requests/users.

Upvotes: 1

Doug
Doug

Reputation: 5328

It sounds like, from your reference to "Page_Load", that you are implementing this in a ASP.NET web form. If that is the case and you are trying invoke a web service asynchronously then you should use the Begin and End invoke functions of the service. This works especially well if you need to call multiple web service at the same time instead of calling them one at a time synonymously.

Enjoy!

Upvotes: 0

Russell
Russell

Reputation: 17737

A Background Worker will take extra time to create and destroy the thread for the background worker. If it is a small piece of code (processing-wise) it may be faster to use the main UI thread.

If maintainability is the key, perhaps using Background workers for processing may be the solution. A custom framework of sorts that automatically dealt with the detail may make the code even more maintainable.

It depends on several factors:

  • The number of small/large pieces of code - this will effect the number of threads running at the same time.
  • The importance of responsiveness and performance for the application
  • The importance of maintainability/scalability for the application.

Upvotes: 1

Justin
Justin

Reputation: 86799

Its good to stick potentailly long-running code into a background worker so that your application remains responsive, but there is no need to put everything as a background worker.

If your code calls a web service (or any sort of external system that might time out), or does something that it likely to take longer than a few seconds, then that would be a good candidate for putting into a background worker, however if anything consistently takes less than a second or so to execute I proabably wouldn't bother.

Upvotes: 1

Robert Harvey
Robert Harvey

Reputation: 180958

BackgroundWorker is normally used to make a Winforms UI more responsive. You can use it for background processing in a web application, but I don't; I use a ThreadPool in a Windows Service.

Upvotes: 1

Related Questions