With Mozilla 1.1a working with IMAP mails with attachments became horrible slow, as the transfer time for the attachments is something about 10k/s (working on local 100Mbit/s LAN). As although the attachment is not displayed (especially with Word and Powerpoint files) the whole files is downloaded (not just the IMAP header) very slowly, making Mail/News very unresponsive. When trying to save the attachment it downloads the attachment again, again very very slowly. In Mozilla 1.0 this worked by far faster (although attachments were also downloaded before being displayed or saved)
I have to revise my original bug, as I tried now to move such a mail to local folders (which again was horribly slow). After restarting mozilla and saving the mail from the local store it took 35 secs for a 2Mb Mail to be saved... quite... slow. So not related to IMAP I guess (opening the mail for reading is faster on local store although)
Component: Networking: IMAP → Attachments
Summary: IMAP Mails with Attachments horrible slow → Mails with Attachments horrible slow (read and save)
I've tried again with Mozilla 1.1b now, and things are now even worse. Mail/News is near unusable after the first mail with attachment is touched.
bug 153819 may be about the same thing. How is the CPU usage during this?
This actually seems very related to bug 153819, as I experiance also very high CPU usage (haven't tested on an unloaded machine as my HP-UX workstation runs background tasks all the time). I found memory usage to be greater than 100MB after downloading (which actually takes up to 3min for files around 3Mb). This is a real blocker for my deployment of Mozilla for my workgroup (around 30 people which are still stuck with Netscape 4.78) If there are more people out there having the same problems maybe the priority should be raised.
i don't notice anything working with 100mb/lan using mozilla 1.1b (2002072104) on win2k. I tried loading a 3mb (maybe 7 secs) and 1.5 mb (maybe 3 secs) imap mail mesg and it didnt take very long. Doing a save as didn't take long either. CPU didn't shoot up to 100%. Using Netscape mesg server 4.15
QA Contact: yulian → stephend
Running mozilla 1.3a, the IMAP-mail works reasonable well, now only the interface itself is the problem. Only forward, does take quite long, because the attachment is fetched from the server first. But that is more an architectural problem. So I guess that bug can be closed.
Still a problem here. I have a dual-boot machine, Linux and Win98SE. Mozilla 1.3 final on each partition, reading mail from an IMAP server on a 100 Mb LAN. When opening a 9 MB attachment, the Windows Mozilla takes over 3 minutes to open the file (or to save it to disk, same thing). The Linuz Mozilla is done in about 5 seconds. Not sure what's going on.
More info on my previous comment: I've just accidentally discovered that, while waiting for the 9 MB attachment to load, if I open a mozilla web browser session in another window, the mail attachment completes loading almost instantly. The "instant completion" only works if I open the mozilla web browser while waiting for the attachment, not if I open a different application. It also doesn't work if the mozilla web browser was already open before starting to load the attachment. And I checked my CPU usage while waiting for the attachment to load and it was around 50%, so not pegged at 100 or anything.
http://bugzilla.mozilla.org/show_bug.cgi?id=210648 - these are almost the same except the high cpu load
Assignee: mscott → nobody
QA Contact: stephend → attachments
Product: Core → MailNews Core
Do you still see the problem using current beta release? http://www.mozillamessaging.com/en-US/thunderbird/early_releases/ And can you attach a sample message to the bug? (save message as .eml file, zip, and attach)
Whiteboard: closeme 2009-02-15
RESO INCO per lack of response to last comment. If you feel this change was made in error, please respond to the bug with your reasons why.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.