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