0

I am using Multithreading in my while loop , as 

while(reader.read())
{
 string Number= (reader["Num"] != DBNull.Value) ? reader["Num"].ToString() : string.Empty;
  threadarray[RowCount] = new Thread(() =>
  {

  object ID= (from r in Datasetds.Tables[0].AsEnumerable()
                                            where r.Field<string>("Num") == Number
                                            select r.Field<int>("ID")).First<int>();


 });

                threadarray[RowCount].Start();
                RowCount++;
}

But with sequential execution ,for 200 readers it just takes 0.4 s but with threading it takes 1.1 sec... This is an example but i have same problem when i execute it with number of lines of code in threading with multiple database operations.

for sequential it takes 10 sec for threading it takes more...

can anyone please suggest me?

Thanks...

Anita
  • 11
  • 1
  • 1
  • 1
    suggest what? Threading and synchronization have overheads, as you see. – Oded Aug 03 '12 at 15:25
  • How are you multi-threading it? Threads don't come for free, perhaps you are running too many things in parallel and causing thread starvation. – Adam Houldsworth Aug 03 '12 at 15:25
  • What your executing in your threads doesn't seem to vary either or am I missing something? As for a suggestion do it sequentially. It seems to be quicker... – Chris Aug 03 '12 at 15:28
  • suggest u read this.. awesome article that speaks about the performance of multi-threading http://msdn.microsoft.com/en-us/library/ms810437.aspx – Vinoth Aug 03 '12 at 15:28
  • paste your normal(non threaded) code? ... just some guesses : threading has an overhead and obciously your taks are so small that the overhead is proving to be bad for performance. also you are creating new threads for every thing ( only limited number of threads can run on a machine at a given time. Thread pool should improve performance perhaps). – Osama Javed Aug 03 '12 at 15:30

5 Answers5

2

Threading is not always quicker and in many cases can be slower (such as the case seen here). There are plenty of reasons why but the two most significant are

  • Creating a thread is a relatively expensive OS operation
  • Context switching (where the CPU stops working on one thread and starts working on another) is again a relatively expensive operation

Creating 200 threads will take a fair amount of time (with the default stack size this will allocate 200MB of memory for stacks alone), and unless you have a machine with 200 cores the OS will also need to spend a fair amount of time context switching between those threads too.

The end result is that the time that the machine spends creating threads and switching between them simply outstrips the amount of time that the machine spends doing any work. You may see a performance improvement if you reduce the number of threads being used. Try starting with 1 thread for each core that your machine has.

Multithreading where you have more threads than cores is generally only useful in scenarios where the CPU is hanging around waiting for things to happen (like disk IO or network communication). This isn't the case here.

Justin
  • 84,773
  • 49
  • 224
  • 367
1

Threading isn't always the solution and the way you're using it is definitely not thread-safe. Things like disk I/O or other bottlenecks won't benefit from threading in certain circumstances.

Also, there is a cost for starting up threads. Not that I would recommend it for your situation, but check out the TPL. http://msdn.microsoft.com/en-us/library/dd460717.aspx

Jeffrey Kevin Pry
  • 3,266
  • 3
  • 35
  • 67
0

Multithreading usually is a choice for non blocking execution. Like everything on earth it has its associated costs.

For the commodity of parallel execution, we pay with performance.

Usually there is nothing faster then sequential execution of a single task.

It's hard to suggest something real, in you concrete scenario.

May be you can think about multiple process execution, instead of multiple threads execution.

But I repeast it's hard to tell if you will get benefits from this, without knowing application complete architecture and requirements.

Tigran
  • 61,654
  • 8
  • 86
  • 123
0

it seems you are creating a thread for each read(). so if it has 200 read(), you have 200 threads running (maybe fewer since some may finished quickly). depends on what you are doing in the thread, 200 threads running at the same time may actually slow down the system because of overheads like others mentioned.

multuthread helps you when 1) the job in the thread takes some time to finish; 2) you have a control on how many threads running at the same time.

in your case, you need try, say 10 threads. if 10 threads are running, wait until 1 of them finished, then allocate the thread to a new read().

if the job in the thread does not take much time, then better use single thread.

urlreader
  • 6,319
  • 7
  • 57
  • 91
0

Sci Fi author and technologist Jerry Pournelle once said that in an ideal world every process should have its own processor. This is not an ideal world, and your machine has probably 1 - 4 processors. Your Windows system alone is running scads of processes even when you yourself are daydreaming. I just counted the processes running on my Core 2 Quad XP machine, and SYSTEM is running 65 processes. That's 65 processes that have to be shared between 4 processors. Add more threads and each one gets only a slice of processor power.

If you had a Beowulf Cluster you could share threads off into individual machines and you'd probably get very good timings. But your machine can't do this with only 4 processors. The more you ask it to do the worse performance is going to be.

Cyberherbalist
  • 12,061
  • 17
  • 83
  • 121