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.

+1  A: 

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.

Robert Harvey
+1  A: 

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.

Having trouble agreeing. How long it **typically** takes isn't important here. What's important is how long it **could** take (worst case).
+1  A: 

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.


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.


The OP clarified this in the comment. I will adjust the question to fix the mistake.
+1  A: 

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, and you may cause your app to become less responsive overall at some threshold of concurrent requests/users.

+1  A: 

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.

Paul Keister
Thank you. I'll "Hello World" asynchronous web service. :P
+2  A: 

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.

This was the problem we had. Some code calls web_service in Form_load but the web_service is delay sometime, the UI becomes unresponsive and client think its broken. Previous software was in powerbuilder and was converted into C#, turn every function into web_service. They are expecting faster then the previous software but we are pulling twice much data then before :'(.Thank your reply.