Performance - Thread vs. Message Pump
-
I'm making a simple VC6 MFC dialog application that, when you push a button, pops up a small dialog that has a progress control and an action button. When you press the button, it performs a lengthy iterative task and reports its progress via the progress control; the action button changes from "Go" to "Stop", such that a second press will cancel the lengthy task. If the task completes, it simply dismisses the dialog; if the user cancels the task, the button returns to "Go" and the dialog stays. Not being a guru in multithreaded applications, I used my old standby peek-and-pump message dispatcher in the loop to handle the Cancel activity. I also tried for the first time to use a worker thread to perform the same task. They both worked, but the threaded version took almost 3 times as long to complete. To distill the problem, I wrote another pair of applications that just write 1,000,000 numbers sequentially to a text file (print the for-loop iterator). I get the same result. The peek-and-pump version takes 5.2 seconds, while the thread version takes 12.5 seconds. Granted this isn't a big difference, but the original application updates a very large database and runs on the order of 2 minutes vs. 5½ minutes. Is this difference in performance to be expected? Thanks, [gb] -- I've killed again, haven't I?
-
I'm making a simple VC6 MFC dialog application that, when you push a button, pops up a small dialog that has a progress control and an action button. When you press the button, it performs a lengthy iterative task and reports its progress via the progress control; the action button changes from "Go" to "Stop", such that a second press will cancel the lengthy task. If the task completes, it simply dismisses the dialog; if the user cancels the task, the button returns to "Go" and the dialog stays. Not being a guru in multithreaded applications, I used my old standby peek-and-pump message dispatcher in the loop to handle the Cancel activity. I also tried for the first time to use a worker thread to perform the same task. They both worked, but the threaded version took almost 3 times as long to complete. To distill the problem, I wrote another pair of applications that just write 1,000,000 numbers sequentially to a text file (print the for-loop iterator). I get the same result. The peek-and-pump version takes 5.2 seconds, while the thread version takes 12.5 seconds. Granted this isn't a big difference, but the original application updates a very large database and runs on the order of 2 minutes vs. 5½ minutes. Is this difference in performance to be expected? Thanks, [gb] -- I've killed again, haven't I?
My guess is you're seeing the overhead of context switching between threads. Keep track of the time since the last progress update and only report the progress every X milliseconds. 250ms is a good starting point, but you can increase that time if you don't mind fewer updates to your progress UI. --Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ "Just because the box has 2 gigabytes of memory doesn't mean you get to use it all!" -- Rico Mariani, CLR perf guy
-
I'm making a simple VC6 MFC dialog application that, when you push a button, pops up a small dialog that has a progress control and an action button. When you press the button, it performs a lengthy iterative task and reports its progress via the progress control; the action button changes from "Go" to "Stop", such that a second press will cancel the lengthy task. If the task completes, it simply dismisses the dialog; if the user cancels the task, the button returns to "Go" and the dialog stays. Not being a guru in multithreaded applications, I used my old standby peek-and-pump message dispatcher in the loop to handle the Cancel activity. I also tried for the first time to use a worker thread to perform the same task. They both worked, but the threaded version took almost 3 times as long to complete. To distill the problem, I wrote another pair of applications that just write 1,000,000 numbers sequentially to a text file (print the for-loop iterator). I get the same result. The peek-and-pump version takes 5.2 seconds, while the thread version takes 12.5 seconds. Granted this isn't a big difference, but the original application updates a very large database and runs on the order of 2 minutes vs. 5½ minutes. Is this difference in performance to be expected? Thanks, [gb] -- I've killed again, haven't I?
Office Lineman wrote:
They both worked, but the threaded version took almost 3 times as long to complete.
Multi-threaded applications on a uni-processor machine generally run slower.
"Take only what you need and leave the land as you found it." - Native American Proverb
-
My guess is you're seeing the overhead of context switching between threads. Keep track of the time since the last progress update and only report the progress every X milliseconds. 250ms is a good starting point, but you can increase that time if you don't mind fewer updates to your progress UI. --Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ "Just because the box has 2 gigabytes of memory doesn't mean you get to use it all!" -- Rico Mariani, CLR perf guy
Having not written (or really considered) explicitly multithreaded applications in nearly 7 years, I had forgotten about those two words: "context switch". Lowering the frequency of the progress update is a generally good idea, which I will implement shortly. Unfortunately, even removing the progress update completely, I'm still experiencing about a 2:1 slowdown. I suspect this threaded program will run better--at least closer to the peek-and-pump program--when I get to my HT-enabled computer, as DavidCrow's observation would imply. Thanks a lot! :-D [gb] -- I've killed again, haven't I?
-
Office Lineman wrote:
They both worked, but the threaded version took almost 3 times as long to complete.
Multi-threaded applications on a uni-processor machine generally run slower.
"Take only what you need and leave the land as you found it." - Native American Proverb
Wow. I forgot I had an old dual 500-MHz machine here. I changed the progress update frequency on both applications, then took this test to it. I had to bump the test up to 100,000,000 iterations to tell the difference! The peek-and-pump program took 47.6 seconds, and the threaded program took 46.8. You guys are awesome. I officially unfurl my brow at the worker thread. :laugh: Thanks, [gb] -- I've killed again, haven't I? -- modified at 15:29 Wednesday 21st December, 2005