Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>For the best performance !</p> </blockquote> <p>You should pick from these options not because of performance, but because of the facilities they provide.</p> <p>Out of those options, <code>BackgroundWorker</code> has the best facilities.</p> <ul> <li>It directly supports cooperative thread cancellation (<a href="https://stackoverflow.com/q/8006040/232593">the only correct type</a>)</li> <li>It supports an interface for pushing updates to your UI</li> <li>It supports automatic thread pooling.<br> This can increase performance due to the system not having to spawn new threads to satisfy your request, but instead allocating from an existing pool of threads.</li> </ul> <p>The other two options don't have quite as nice facilities built in. In a nicely implemented UI application, you'd have to build them yourself, and I don't think most people would do much better perf-wise than the implementations for <code>BackgroundWorker</code> without a lot of work.</p> <p>You might also want to consider <a href="http://msdn.microsoft.com/en-us/library/dd460717.aspx" rel="nofollow noreferrer">the Task Parallel Library in .Net 4.0 and above</a>. It supports cancellation, more direct integration into the language, chained and dependent tasks, and other interesting features.</p> <blockquote> <p>[From comments:] Im not concerned - I just want to know the difference</p> </blockquote> <p><a href="http://msdn.microsoft.com/en-us/library/system.threading.thread.aspx" rel="nofollow noreferrer">Thread</a> is the original construct out of all these. It provides basic threading support in .Net. It is low level and should be avoided unless you don't have a better option that fits your needs.</p> <p><a href="http://msdn.microsoft.com/en-us/library/22t547yb.aspx" rel="nofollow noreferrer">Delegate.BeginInvoke</a> is a hook for allowing someone to create a task-based threading library. Someone can pass that library a delegate, or that library could store a list of delegates. From these it would call <code>BeginInvoke</code> on them to spawn threads. These threads are allocated from a thread pool. This is a building block, though at a higher level than <code>Thread</code>. There are higher level facilities you probably want to use.</p> <p><a href="http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx" rel="nofollow noreferrer">BackgroundWorker</a> is the most user friendly out of these options. It is most useful for UI (GUI or command line) applications where you want to provide the user feedback about the status of a specific background task. It also supports cooperative cancellation. Both of these things are extremely common.</p> <p>There are other facilities you didn't mention, like <a href="http://msdn.microsoft.com/en-us/library/3dasc8as(v=vs.80).aspx" rel="nofollow noreferrer">using thread pools directly</a>, or the task parallel library. Those are suited to yet other tasks, and are worth a look and consideration.</p> <blockquote> <p>And please, give me deep explanations, not like 'I guess' :)</p> </blockquote> <p>People cannot guess perf for code they cannot run. As a general rule for thread perf, you probably shouldn't be concerned about it unless you're writing an extremely processor intensive algorithm. And then you should usually be concerned with your algorithm and making it <a href="http://en.wikipedia.org/wiki/Amdahl&#39;s_law" rel="nofollow noreferrer">fully parallelizable</a> <em>before</em> worrying about low level details like perf of the thread facility.</p> <p>You should definitely profile your code to determine the bottlenecks in your codebase and see if you can improve them. You can't preempt profiling with a set of programming rules.</p> <blockquote> <p>Fetch data from database to control - or serius background calculation !</p> </blockquote> <p>DB fetch is IO bound, not CPU bound. This is a case where you're threading to wait on a background task, not threading to maximize CPU usage. Don't worry about thead perf in such a scenario.</p>
    singulars
    1. This table or related slice is empty.
    1. POThreading troubles - when should I and when should I not thread, for best performance?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USMerlyn Morgan-Graham
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POThreading troubles - when should I and when should I not thread, for best performance?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COIm nor concerned - i just want to know the diffrence ! (in some case its extremely processor intensive algorithm)
      singulars
      1. PO
      1. USNiklas
    2. CO@Niklas: Is it spawning multiple sub-tasks? If so, then I might look into the task parallel library, especially `Parallel.ForEach`. But the main task thread itself might still use a `BackgroundWorker`.
      singulars
      1. PO
      1. USMerlyn Morgan-Graham
    3. CO@Niklas: "in some case its extremely processor intensive" doesn't match any of the scenarios in your original question. You might want to clarify what type of CPU-bound activity you need threads for, and mention the type of analysis you've done on parallizability of the code. See [Amdahl's Law](http://en.wikipedia.org/wiki/Amdahl's_law). Until you've done that analysis and maximized/switched your algorithm to maximize parallizaibility, the perf of the thread pool or thread spawning code will be a moot point. For most scenarios it probably won't have as much impact as you think.
      singulars
      1. PO
      1. USMerlyn Morgan-Graham
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload