• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 755
  • Last Modified:

Windows Message Queue and Processor Performance

Hello all,

I'm new to windows programming, and there is something that really confuses me.

I am working on legacy code where the application logic is contained in various OnTimer calls in an MFC dialog based program that runs on a WinXP embeded system.

What appears to be happening is that the program spends "to long" in the timer event handler before responding to other messages like button clicks and such.  This causes a noticable delay in the system responsiveness when user interface features are used.

However, when I look at my processor usage in task manager, the processor is barely being utilized.  If there are events in my windows queue, and meaninful work to be done, why isn't the processor being used more?  The code that gets processed in the timer event handler does not use any Sleep, mutex, or file IO function, so why the holdup?

I am in the process of moving most of the application logic to different threads to free up the user interface thread, but it would be really helpful if, atleast temporarily, I could increase the CPU timeslice or some other "parameter" to improve processor usage for the application.  We use Microsoft's Target/component designer to build customized WinXP images, so maybe there's something in there I can change?



0
StixGP
Asked:
StixGP
  • 2
  • 2
2 Solutions
 
jkrCommented:
>>The code that gets processed in the timer event handler does not use any
>>Sleep, mutex, or file IO function, so why the holdup?

So how exactly does the code look like?
0
 
SysExpertCommented:
Not sure, but if onTimer is  being used, shouldn't calls to the OS to return to the main process or Giveup time be made if the process is waiting for stuff, and not actually doing anything.

This is especially true for any wait loops.

I hope this helps !
0
 
StixGPAuthor Commented:
>>The code that gets processed in the timer event handler does not use any
>>Sleep, mutex, or file IO function, so why the holdup?

It appears I was wrong....big time...

The section of code i've been referring to is tied to an ActiveX control sitting on the main dialog.  One of the object's member function (didnt see it at first) does a file I/O operation that takes on average 210 clock() ticks. That definetly explains the idle time and lag in the user interface.

This operation is necessary to update the ActiveX control (MapObjects 2.2 by ESRI).  The code updates the maplayers recordset, and the map then refreshes on its timer message.  I don't think I can move the recordset update code to another thread because the mainthread is updating the map in real time and I doubt MapObjects is threadsafe.

Any suggestions on how I can improve the UI responsiveness?

0
 
SysExpertCommented:
DO a release back to the OS immediately before and after the fileIO

0
 
jkrCommented:
>>Any suggestions on how I can improve the UI responsiveness?

Move that code into a thread and use

   MSG                 msg;

   HANDLE hThread = CreateThread ( ...);

   while   (   WAIT_OBJECT_0   !=  MsgWaitForMultipleObjects   (   1,
                                                                   &hThread,
                                                                   FALSE,
                                                                   INFINITE,
                                                                   QS_ALLINPUT
                                                               )
           )
           {
               while   (   PeekMessage (   &msg,   NULL,   0,  0,  PM_REMOVE))
                       {
                           DispatchMessage     (   &msg);
                       }
           }

to wait for it to end. The loop will take care of dispatching messages and keeping the UI responsive.
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now