jesup@steinmetz.steinmetz.UUCP (Randell Jesup) (08/26/87)
In article <211@dana.UUCP> rap@dana.UUCP (Rob Peck) writes: >Just to be sure nobody gets the wrong idea - it is indeed possible to >slow down the machine to a point where you can't really get good >performance out of an interactive task. Yup. >Amy did not >miss a keystroke, but kept them invisible for so long that it made >it difficult enough to use I just hadda wait till the download was >done. > >I suspect that the program, COMM 1.34, might possibly be communicating >with the serial device in a gimmee-one-character-per-message-passed >mode thereby and with characters coming in continuously at 1200 baud >it may have kept the system busy enough to keep my microemacs at a >lower priority. Also, it was probably doing 1 character writes to the ramdisk. That's bad, as the ramdisk it totally CPU bound. Dumping it to disk may actually be better in a case like this. In fact, if you had set the priority of the CLI that spawned the editor before running it to 1, there would have been little slowdown (except from the ramdisk, which runs at something like 20). What we really need is a pop-up or daemon program to allow the user to change the priority of the program they're running, sort of like the color-modifier pop-ups. Any volunteers??????? Don't forget, it would be real nice if would come up on the screen with the active window.... >Rob Peck ...ihnp4!hplabs!dana!rap Randell Jesup jesup@steinmetz.UUCP (uunet!steinmetz!jesup) jesup@ge-crd.arpa