tobeye@NORTHSTAR.DARTMOUTH.EDU (Anthony Edwards) (07/11/90)
I am a big messages supporter at our site. I think it really enhances mail messages to be able to use italic, special fonts, or insets. However, I have a confession. I don't always use messages. I use /ucb/mail as well. Messages is just too slow. I have a .AMS.flames file which is very busy (it sorts up to 50 user ids into one of 12 folders). We're also connected via AFS 3.0 to CMU's bboards (thus how I read info-andrew). Just to read in new mail (say 2 to 4 messages) can take up to a minute. That's ridiculous. I find myself telling messages to read my mail and then coming back to the program 5 minutes later to see what mail I got. THEN, clicking on mail messages doesn't promptly bring up my message. I typcially see a 2-4 second delay. (Remember that the typical user's patience is .5 seconds for computer response). So, these days, I typically read my mail with /ucb/mail (unless it's ATK formatted) and then let messages go and sort my mail into appropriate folders. Do other people have similar problems? To be fair, my problem may stem from my heavy use of FLAMES (so, therefore, maybe I should be flaming FLAMES...?) I remember a discussion a while back initiated by Nathaniel to take the dynamic loading out of these ATK programs to improve their speed. Maybe that could be a workable solution. (System spec: I'm running messages on an IBM RT, running AOS 4.3, with 8 Mb of memory. I may have the memory for UNIX, X, and Messages to all run happily, but then where's the memory for me to do what my job is...?) - Anthony
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/11/90)
Yes, even I have the same problem from time to time. My own observation is that the performance of Messages is very critically sensitive to a number of factors: system memory, paging, and file system & network performance. When all is going well, Messages runs quite quickly, but when any of these factors becomes a problem, performance deteriorates quickly and dramatically. The bottom line, I guess, is that Messages uses a lot of resources and the performance degradation when any of them is scarce is not what you'd call graceful. What I don't know is an easy way to determine what the problem is in any specific circumstance. Basically, it's just trial and error. (For example, you could try getting rid of your FLAMES file temporarily to see if that's the problem, though I doubt that it is unless it is very inefficiently written. Similarly, you could temporarily move your .MESSAGES tree onto the local disk to see if your file system is the problem.) The specific behavior you describe sounds most likely to be file-system-related to me. 2 to 4 second delays when you click to read a new message are just unreasonable. They don't happen to me here. If they happen to you regularly, I'd suspect the file system. Does it take that long to "cat" an arbitrary file in the messages database? If so, the file system is definitely the problem. If not, the next question would be how much swapping is going on... -- Nathaniel
bader+@ANDREW.CMU.EDU (Miles Bader) (07/11/90)
I know few andrew users that actually use an AMS mailer to read their mail. I use more(!). If it's something I want to deal with, I'll let AMS churn on it for a while and answer it later. The process could almost certainly be sped up (at what cost, I don't know), but dynamic loading time is not the problem (it's just as mind-bendingly slow when you're using a long-running messages). I also doubt that not having the AMS code be shared (a side-effect of it's being dynamically loaded) is any big deal, since very few people run >1 simultaneous AMS programs [although there might be things like AFS libraries that might be productively shared between, say, AMS & console; I'm not really sure]. -Miles
Craig_Everhart@TRANSARC.COM (07/11/90)
I use Messages all the time for my mail. Am I an exception among Andrew users? For that matter, several folks at Transarc use Messages all the time even though ATK isn't officially supported here. When I had a Flames file, I thought that it slowed down the incorporation of new mail a lot. I ultimately traced the problem down to the fact that I was running Messages 7.8 (on a pmax), whereas the current Messages 7.14 contains a substantial performance fix so that Flames-based message incorporation goes MUCH faster. If your complaint is about message-incorporation time, try eliminating your .AMS.flames file and seeing if that makes a timing difference. If so, try building a newer Messages with newer source files. This particular machine is pretty rich, so displaying the next message is a pretty quick operation (or quick enough for me). It will usually be pre-fetched, and the ATK-related overhead of building the display seems manageable. I just tried a couple of tests, and it seems like it's a 1-second delay or less. (Fresh copy of Messages, file servers not that distant. Yes, this old Messages (7.8) also eats/leaks memory, so you have to restart it occasionally or it will really bog down.) Craig
janssen@parc.xerox.com (Bill Janssen) (07/11/90)
I use messages exclusively (on a Sun-4/260, 32MB, SunOS 4.0.3). Even over the phone lines on a X terminal... I have a fairly bulky .AMS.flames file. It does take too long (5-15 seconds) to sort, say, 10, new messages. But individual messages come up instantly, and any delays seem to correlate well with file-server problems. I wonder if running a daemon cui job that continuously read and sorted your mail would help? It would break tools like biff or the console mail display, but it would offload the sorting overhead. My pet peeve is message drop-off time between `sendmessage' and /usr/lib/sendmail. It hangs for dozens of seconds -- unlike /bin/Mail, or GNU Emacs's version of sendmail. Why is that? And why should the mail-reading tool be locked up during that time? Why isn't that forked off in the background? Are there some sendmail switches set wrong? Bill
tom@ICASE.EDU (Tom Crockett) (07/11/90)
Well, I use messages exclusively, running on a Sun 4/60 with 16 MB, and
the performance is generally quite good (I started out using it on a 4
MB diskless Sun 3/50, which was just plain awful). Because it takes so
long to start up, I usually fire it up at most once a day, and just use
the Check New Messages or Read Mail menu entries to fetch incoming mail.
I usually have no significant delays when clicking on a new mail
message -- it's usually pretty snappy, even though my ~/.MESSAGES
directory and our local bulletin boards are on remote fileservers.
I have to agree, though, that FLAMES is unacceptably slow. Surely there
is room for improvement here, but maybe not within the context of an
embedded Lisp interpreter. Which brings me to another pet peeve I have
with FLAMES. Our shop is heavily into scientific computing and
numerical analysis, i.e. FORTRAN, and very few of our users are at all
comfortable with Lisp. For computer scientists, a Lisp-based mail
sorting language may be O.K., but it's pretty intimidating for a lot of
our engineers and mathematicians. Given that one of the most useful
features of messages is its ability to sort mail, I think a simpler,
faster, more accessible interface is definitely in order.
I've also considered running a cui daemon to sort my personal mail, as
Bill Janssen suggests. While this does have some disadvantages, it
should help to hide the sorting delays incurred by FLAMES. We're
running a bulletin board daemon which does just that for public folders,
and it works fine.
Overall, though, I think messages is the greatest thing since sliced bread.
Tom Crockett
ICASE
Institute for Computer Applications in Science and Engineering
M.S. 132C e-mail: tom@icase.edu
NASA Langley Research Center phone: (804) 864-2182
Hampton, VA 23665-5225