none
Windows CE 6.0 R3: Performance Issue: High CPU Utilization: Updating Silverlight text box consumes CPU unusually high RRS feed

  • Question

  • Hi,

    We are developing a patient monitoring device in Windows Ce 6.0, R3 on i.MX27L platform. It has silverlight GUI screens created using Expression Blend 2. One of the screens has text boxes to be filled by doctor to register Patient's name, last name, etc. There are multiple algorithms to process heart rates, uterine activities, etc running in the background along with the GUI.

    Problem: High CPU Utilization by Silverlight to update any of text boxes for every character input from a USB 2.0 Keyboard.

    Following tests were done to arrive at the above conclusion:

    1. Windows CE was launched and only word pad was opened. Characters were typed into the word pad document. The Performance Monitor showed a surge of 2.24 % (=A) for every key press.

    2.Windows CE was launched and the full-fledged application with Silverlight GUI was executed. Characters were typed into the GUI's text box using usb keyboard. The performance monitor showed a surge of 71.43% (=B) for every key press.

    3. Now, the silverlight application was minimized. This was to make sure that algorithms and other modules of the application continue to keep running in the background. Word Pad was opened and instead of typing characters into GUI, they were typed into the word pad. The performance monitor showed a surge of 11.54% (=C).

    Hence, the amount of cpu consumed by silverlight to update the text box was = B-C = 71.34 - 11.56 = 59.78 %

    CPU utilization overhead due to other modules in the application was approximately = C-A = 11.56 - 2.24 = 9.32% only.

    Is there any solution to above problem? Please help.

    Regards,

    Neil

     

     

    Wednesday, August 11, 2010 12:50 PM

All replies

  • Although you can certainly subtract things and arrive at that sort of conclusion, the 59.78% number is completely meaningless.  It's only a problem if you can't actually do what you want to do.  If the task manager in Windows XP shows 99%, so what?  It's not a problem unless you try to do something and you can't.  The same is true of Windows CE.  You're convincing yourself that there's a problem based on a relative consumption of some resource.  As long as it's less than 100%, you have more cycles available, so that seems fine to me.

    Paul T.

    Wednesday, August 11, 2010 3:21 PM
  • Hi Paul,

    Thanks for your reply. I do understand that as far as utilization is less than 100%, the system has enough cycles to service other processes, but our conclusion of 59.78% of utilization is significant in the following context:

    The reason for our concern is simple: there are lots of more modules to be integrated into the system that will execute simultaneously with the existing functionalities during the above test:

    1. Printer to print real-time data

    2. At least 3 communication protocols to interact with remote server(s) via ethernet and serial

    3. More algorithms for patient monitoring parameters, etc.

    The worst is that with the existing modules, CPU utilization touches 100% if I update GUI text boxes using touch panel or a usb mouse. Further, a touch event or a usb mouse movement event across GUI are marked by 98% to 100% of CPU. This is affecting the application's responsiveness.

    A 400MHz processor should be capable of doing all these tasks simultaneously at a lesser utilization, for similar older products with inferior processors have maximum CPU utilization of 70% in all circumstances. They take up not more than 8% of CPU if all the input devices - touch panel, keyboard, and a knob are used together on their GUIs. The only differences are the OS and GUI. Our platform may not match these numbers, but we're looking forward to reducing this utilization so that the system always have enough cycles for all upcoming functionalites. Unless we resolve these high cpu consumptions, our progress is at stake.

    We've proofs from kernel tracker for proving that critical patient monitor threads do get executed at their desired timings inspite of the high cpu utilization. In that case, the system/Wince does what it should do, but the system should be responsive as seen by the end-user too.

    From this point of view,

    Regards,

    Neil

    Thursday, August 12, 2010 5:23 AM
  • Ah, we're still at that problem.

    As I think I mentioned in the other thread, the Silverlight behavior sounds wrong to me, but we aren't able to do anything about it in this forum.  You'd have to start a support incident, reporting the behavior as a bug, and asking for a QFE to fix it.  If that doesn't happen, you're stuck and it's likely that nothing else the you do is going to 'fix' anything.  Whatever Silverlight is doing does not appear to be controllable by you.  You still have the option of dropping Silverlight, at least for now.

    So, if it were me, while a utilization number might be of some concern, I'd still not really be worried until I saw a real problem with the real-time stuff or the UI responsiveness.  Processor utilizations are still just numbers and don't rise and fall linearly with added code that needs to be executed.  My own experience with those percentage numbers is that they're garbage.

    You've identified the biggest problem.  The right way to proceed is to eliminate the problem entirely, get it fixed, or move to a faster processor (or one with hardware support for whatever it is that Silverlight is trying to do and taking so many cycles to attempt).

    Paul T.

    Thursday, August 12, 2010 8:35 PM
  • The Silverlight, of course, eats up cpu, but actually it is GWES component that takes around 40% extra processor in all cases : whether a usb mouse or touch panel is moved continuously over silverlight or similar gui created in MFC or on Windows CE desktop. And it the UserInputThread that is the most cpu intensive process. But yes, Silverlight does consume more cpu than a MFC GUI.

    Neil

    Friday, August 20, 2010 10:28 AM
  • As you know, movement of a mouse over a window sends WM_MOUSEMOVE messages to that window.  The *handling* of those messages is likely to be significant, but I've never seen the huge bump in processor utilization that you describe with *Win32* windows.  I'm concluding from that a connection with Silverlight.  You could quickly whip up a Win32 program with an EDIT control in it and move the mouse around there.  If that also chews up the processor, you'd have to look at the driver for the mouse or panel.  Remember that MFC also chews up more processor cycles to handle such messages than Win32 does.

    Paul T.

    Friday, August 20, 2010 4:52 PM
  • AFAIK, silverlight defines its GUI with vector graphics, hence rendering may take significant processing power esp on low-end CPUs w/o floating point co-processor. Depending on mouse cursor implementation, I'd guess moving the cursor over silverlight GUI may cause redraws and likely it causes silverlight to search for control targets through its vector-defined layout. And even with minimized window, silverlight rendering engine may waste time updating its off-screen buffers. I wonder if it is a right tool for a mission-critical application.

    Michal

    Thursday, September 23, 2010 4:47 PM