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 08830wagner@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