On Tue, 29 Mar 1994 15:23:43 -0500 David Barr <[log in to unmask]> said:
 
><1  to 2  second delays  for  _each_ message  constitutes a  significant
>amount of overhead.
 
Wall clock time, not CPU time!
 
>However,  things could  be faster  if it  were possible  to implement  a
>MAILER+SMTP combo which actually could  do all the work required, rather
>than passing all messages between (slow) reader spools.
 
Yeah,  on a  slow machine  the messages  would take  1-2 seconds  less to
arrive, and  on a fast machine  there would be no  noticeable difference.
Big deal!
 
>Wasn't  it  someone  on  this  list  who  made  an  observation  on  how
>disk-intensive the process is on CMS?
 
That's  SMTP itself.  It was  written by  people with  a big  machine and
little  traffic. It  doesn't use  the disk  efficiently. It  creates temp
files where  none are needed,  etc. If  you send a  big piece of  mail to
yourself, LMail will put it in your  mailbox in a fraction of the time it
took  you to  pass  it to  LMail. The  system  interfaces were  carefully
designed for  efficiency, which is  why it can  beat assembler code  by a
factor of 3.
 
>I was  simply making  the observation  that the  fact that  Majordomo is
>written in  Perl should be  considered a  "plus" in terms  of estimating
>efficiency and  speed, rather than  a "minus". (especially since  I hear
>woes even from you on how bad VM's Pascal is)
 
What I was trying to point out is that algorithms are much more important
than compiler speed.  In particular, there are systems that  scale up and
systems  that don't.  The  old  sendmail didn't  scale  up.  It makes  no
difference whether it's  written in perl, C, or assembler,  I can beat it
with a REXX program that scales up and doesn't fork the machine to death.
It makes no sense to make  claims of relative speed about programs you're
not familiar with based solely on the programming language.
 
  Eric