|
Sender: |
|
Subject: |
|
From: |
|
Date: |
Wed, 30 Mar 1994 22:29:57 +0200 |
In-Reply-To: |
Message of Tue,
29 Mar 1994 15:23:43 -0500 from LISTSERV give-and-take forum
< [log in to unmask]> |
Reply-To: |
|
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
|
|
|