kdd@well.UUCP (Keith David Doyle) (10/09/86)
References: [.........] Some of the recent discussion about terminal emulator performance reminds me of a few things I have noticed lately, in regards to performance in general. Some of you may have come across one of Dale Lucks little utilities, a program called 'PM' (for Performance Monitor) which I recently ran across on a local BBS. (thanx Dale!) I've found PM to be a darn useful utility, as it gives you a little 'chart recorder' style graph of the CPU idle time, and the chip memory usage. There may be other performance monitor programs out there that do similar things. From using PM, I've found that you can VERY EASILY pinpoint the programs that *poll* instead of Wait() for events. When you run a program that polls, the CPU idle time goes directly to ZERO (do not pass go, do not collect $200). Online! is one that polls. A-Talk on the other hand, obviously does a Wait(), as the CPU idle graph, when A-Talk is up but not doing anything, is the same as it is when A-Talk is not up at all. Also, the utility SeeILBM polls, (though I've hacked mine so that it dosen't anymore). I noticed this originally when I was using it to display a picture on the screen while I was doing a Kermit multi-file transfer, and found that the transfer time went WAY down when the picture was on the screen. GAK! Glad I had the source to SeeILBM. Don't have the source to Online!, time to switch to VT100 I guess. PM (or similar utilities) are sure handy when evaluating the behavior of various programs, particularly under multitasking. I find that I do a lot of multitasking when I am using terminal programs, so it is important to me that they do not hog any more CPU than they have to. In addition, I hope that if more of you out there make use of such utilities, that the awareness level of such issues will become high enough so that we will see fewer and fewer programs that are *ill-behaved* in a multi-tasking environment. Ideally, if when an Amiga magazine does a review of a new software product, it would be nice if they would include basic information of this type just as a matter of course. That would force just about everybody to produce more *well-behaved* programs for the machine. Otherwise, what we don't know won't hurt us??? If you look at the stereo magazines, when they rate a new stereo, or whatever, they run all sorts of laboratory tests against them, to test S/N ratio, wow & flutter, etc. Perhaps some multi-tasking performance tests could be a software version of this. So, at any rate, see if you can locate a copy of PM (or maybe Dale will post it to mod.amiga.sources or somewhere, I don't remember it coming across the net though I could be wrong), and test some of your favorite programs to see just what they are doing when they seem to be doing *nothing*. I found it a great little utility and pop it up all the time to see just what the heck is going on in there. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa "You'll PAY to know what you REALLY pay!"
eric@topaz.RUTGERS.EDU (Eric Lavitsky) (10/10/86)
Try running the monitor with DPaint. Perry showed me this earlier this week with a neat monitor he wrote - DPaint only Wait()s while you're in the menu bar about to make a selection. If you move the mouse onto the work surface, it seems to busy wait for mouse movements instead of waiting for a signal that the mouse has moved! Can anyone else confirm this or prove it wrong? Eric -- ARPA: LAVITSKY@RUTGERS or LAVITSKY@RED.RUTGERS.EDU UUCP: ...{ihnp4,pyrnj}!topaz!eric ...hplabs!well!lavitsky ...{decvax,seismo,allegra}!ulysses!eric SNAIL: 629 Cheryl Drive, Iselin, NJ 08830
wagner@utcs.UUCP (10/10/86)
Please post these performance monitors. My training for several years was in performance monitoring, so I have always chaffed when delayed by my Amiga. A good monitor would allow me to understand what was going on inside there (and perhaps make some good suggestions to c=a?). Michael Wagner (wagner@utcs or ...utzoo!utcs!wagner)
tenney@well.UUCP (Glenn S. Tenney) (10/11/86)
Busy waiting, per se, is not ALWAYS a bad thing. If you are expecting alot of interrupts (say tracking a fast-moving mouse) the overhead of wait's etc. might slow things down too much. In the case of DPaint, when you are w/in DPaint's window and it busy waits, WHO CARES! You aren't usually multi-tasking at that point, at least not much. And when you want to do something else, you go up to the menu bar which, as someone said, uses wait. Just remember, there are many considerations. There may be the "right" way to do something, and then the efficient way. Performance of the application might take precedence to not busy waiting. Then, there are times when you might want to do your own multi-tasking (internally) where you may not be able to use wait. -- Glenn Tenney UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY As Alphonso Bodoya would say... (tnx boulton) Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!
eric@topaz.RUTGERS.EDU (Eric Lavitsky) (10/12/86)
[why aren't there line eaters anymo > From: tenney@well.UUCP (Glenn S. Tenney) > > Busy waiting, per se, is not ALWAYS a bad thing. If you are expecting alot > of interrupts (say tracking a fast-moving mouse) the overhead of wait's > etc. might slow things down too much. In the case of DPaint, when you are > w/in DPaint's window and it busy waits, WHO CARES! You aren't usually > multi-tasking at that point, at least not much. And when you want to > do something else, you go up to the menu bar which, as someone said, > uses wait. Why wouldn't I be multitasking? - if I've got oodles of memory, I might start up a file transfer in the background and then fool around in DPaint. A good terminal program will Wait() for characters on the serial port - if I just happen to leave the mouse on the DPaint screen and walk away, DPaint will suck cycles that my file transfer could be using. If anything, DPaint could at least "time out" if it gets no input for a while and then do a real Wait() ... > Just remember, there are many considerations. There may be the "right" > way to do something, and then the efficient way. Preformance of the > application might take precedence to not busy waiting. Then, there > are times when you might want to do your own multi-tasking (internally) > where you may not be able to use wait. > But AmigaDOS provides a task priority mechanism for that purpose - there is no excuse for not behaving well in a multi-tasking environment. > -- Glenn Tenney > UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney > ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY > As Alphonso Bodoya would say... (tnx boulton) > Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS! Eric Lavitsky -- ARPA: LAVITSKY@RUTGERS or LAVITSKY@RED.RUTGERS.EDU UUCP: ...{ihnp4,pyrnj}!topaz!eric ...hplabs!well!lavitsky ...{decvax,seismo,allegra}!ulysses!eric SNAIL: 629 Cheryl Drive, Iselin, NJ 08830