-
January 9th, 2014, 04:57 PM
#1
Lag when clicking MFC file menu
Hello,
I am developing a CFormView MFC app. When I go to click something on the menu, it takes awhile before the event happens. The project is build optimized in release mode. I have 3 additional threads and I thought they might be blocking the internal MFC framework stuff, but I use the Sleep() call in each thread to yield to the MFC main app. What could be going wrong here?
Thanks,
Chris
-
January 9th, 2014, 05:18 PM
#2
Re: Lag when clicking MFC file menu
It is hard to say without seeing your code. Could you post your project?
Victor Nijegorodov
-
January 9th, 2014, 05:25 PM
#3
Re: Lag when clicking MFC file menu
I wish I could, but it is probably too big and too many other external apps interfacing with it via tcp/ip. Sometimes the entire view freezes too. I ran it in the debugger under release mode, and it's not stuck in any endless loop as far as I can tell. Child windows are still updating.
-
January 9th, 2014, 05:29 PM
#4
Re: Lag when clicking MFC file menu
Then try to throw away all unnecessary stuffs creating a small project that can reproduce the problem and post that one here,
Last edited by VictorN; January 10th, 2014 at 04:13 AM.
Victor Nijegorodov
-
January 9th, 2014, 06:58 PM
#5
Re: Lag when clicking MFC file menu
Threads shouldn't block the UI and sleep is almost never a good idea. Does it respond if you don't start the threads? Have you tried running the threads at a lower priority than the UI thread? Does task manager show your cpu is busy when you go to click on the menu? Are you low on physical memory? Do you have menu update handlers that have time-consuming code in them? Are there a lot of files in your working directory? Is your hard drive getting hammered by anything?
-
January 10th, 2014, 07:37 AM
#6
Re: Lag when clicking MFC file menu
Originally Posted by clow
, but I use the Sleep() call in each thread to yield to the MFC main app.
Any app that "needs" to have Sleep() in it's code in order to "make multithreading work"... Probably has some really really nasty bugs in there. Sleep does not solve anything, at best it can seemingly hide problems in specific test cases on a specific machine.
I'm not saying there aren't legitimate usage reasons for Sleep(), but it's used incorrectly more than correctly.
Your description pretty much seems spot on in that, you're waiting for the sleeps() to end before MFC gets to execute its menu handling code...
Remove the sleeps, this will probably solve the lagging UI interface. It it introduces "other problems", it means those other threads aren't doing their job properly.
-
January 10th, 2014, 10:49 AM
#7
Re: Lag when clicking MFC file menu
Originally Posted by OReubens
Any app that "needs" to have Sleep() in it's code in order to "make multithreading work"... Probably has some really really nasty bugs in there.
That's the word of truth. There are very few legit uses of Sleep, in many cases it is used only for simplicity reasons. A polling/pumping mechanism is easier to write than something based on signals.
Nobody cares how it works as long as it works
-
January 13th, 2014, 08:30 AM
#8
Re: Lag when clicking MFC file menu
Originally Posted by zerver
A polling/pumping mechanism is easier to write than something based on signals.
Well, slow down a polling/pumping loop IS the only legit use of sleep I'm aware of, on condition that what you are polling/pumping:
- Is external to your own program (whatever triggers happens in another process)
- you do not own the other process (you don't have sourcecode), OR the other process resides on another machine and for some reason you're not allowed to make use of network communication to synchronise.
For the 2nd case, trying to synchronise file read/writes by using low level file API calls would be a "legit" reason, even though server OSes are making this increasingly more 'flaky' by caching network read/writes/locks, delaying directory change updates over the network and such.
As it stands, as time progresses and new versions of OSes get released, Sleep() (or whatever form of forced slow downs) is getting a worse and worse reputation.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|