Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!trwind!venice!press
From: press@venice.SEDD.TRW.COM (Barry Press)
Newsgroups: comp.windows.ms
Subject: Re: CPU Usage of Word for Windows, PC-PLUS
Message-ID: <1055@venice.SEDD.TRW.COM>
Date: 11 Apr 91 16:55:18 GMT
References: <274@raysnec.UUCP> <4983@czech.sw.mcc.com>
Reply-To: press@venice.sedd.trw.com (Barry Press)
Distribution: usa
Organization: TRW Systems Engineering & Development Division, Redondo Beach, CA
Lines: 35

In article <4983@czech.sw.mcc.com> daneman@czech.sw.mcc.com (Michael Daneman) writes:
>In article <274@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes:
>> 
>> 	Running from the Program Manager, usage typically shows 1-2% -
>> unless I'm really doing something - but if I load MS Word for Windows it
>> shows a typical 95-97% CPU utilization in edit/insert mode, but drops
>
>These number actually sound reasonable to me.  MS Word is a pretty power
>hungry application.  It's CPU usage might drop in 386 enhance mode, but I
>am not sure about that.  As far a ProComm goes, running a DOS application in
>a window takes a lot of CPU time because Windows has to virtualize the
>text screen (where procomm normally write), convert that screen to a
>graphic bitmap and dump that bitmap to the screen at regular intervals.
>Running DOS applications full screen takes considerably less CPU time.

It's somewhat more complicated than that.  The API for the comm ports in
Windows does not provide a message that says "you've got characters to
process", although it does provide interrupt driven, buffered comm.
The implication of this is that a Windows comm program has to continually
poll to see if there's anything in the input buffer.  There are two
ways to do that:

1.	You can set a timer, and every time the timer expires, check the
	buffer.

2.	You can use a call that checks for input messages in the application's
	queue but returns whether or not messages are present.  In the
	same loop, you check the comm buffer.

The net result of these two approaches is that, although the CPU per check is
low and other programs get lots of opportunity to run, if your system is idle
then the comm program can suck up quite a bit of CPU doing the polling.

-- 
Barry Press                                 Internet: press@venice.sedd.trw.com