Suresh Reporter
	Description • 25 years ago

Loading a message in message pane is very slow. It occurs both on POP and IMAP
account.

Build date and platform tested:
1999-11-04-09-M11, windows commercial build.
Platform: Win 95, 133 Mhz, 64 MB RAM.

Additional info:
1. Time taken to load a 10 kb Msg on 11/04 build is ~15 seconds.
2. Time taken to load the same msg on 10/22 build is ~4.5 seconds.

	Phil Peterson
	Comment 1 • 25 years ago

Since this is both POP and IMAP, let's start with rhp.

	lchiang
	Comment 2 • 25 years ago

suresh, do you want to attache a copy of the msg to this bug report?
rhp - does it help if we paste in any output from the DOS console?

	rhp (gone) Assignee
	Comment 4 • 25 years ago

Output isn't really that helpful...but the message would be good.

David, what was the barber poll performance issues that you were working on
before. I have a feeling this may be a part of what we are seeing.

- rhp

	rhp (gone) Assignee
	Comment 5 • 25 years ago

David...forgot to add you on the last update.

- rhp

	rhp (gone) Assignee
	Comment 6 • 25 years ago

The attachment isn't the message contents I need. What I need is the actual
contents of that file from your mail folder. Do this:

- send this message to a 4.x client
- select message
- save it as "BUG.EML"
- attach this file with a content type of "message/rfc822"

- rhp

	rhp (gone) Assignee
	Comment 8 • 25 years ago

*** Bug 17535 has been marked as a duplicate of this bug. ***

	Scott MacGregor
	Comment 9 • 25 years ago

This problem may be related to my bug: Bug #17062 for slow message display times
on Linux. I'm pretty sure that problem is related to all the event queue changes
which did go in between the dates Suresh noticed the problem: 10/22-11/04.

I suspect this is the same problem. Although it's reported on windows and not
linux.

	lchiang
	Comment 10 • 25 years ago

I'm going to nominate for DOGFOOD since this has to do with performance and is
something many people do (read msgs).

	rickg
	Comment 11 • 25 years ago

Putting on PDT radar

	rhp (gone) Assignee
	Comment 12 • 25 years ago

I did some investigation with mscott on this issue. From what we saw, it
doesn't look like libmime OR Necko are the culprits here. Even without getting
exact timing, it was obvious that the OnStartRequest and OnStopRequest are
processed fairly rapidly, and then there is a significant delay after we write
our data to layout.

mscott believes this is due to a forced reflow bug with the throbber running
and we can see what almost looks like a multiple repaint of the message. mscott
is investigating this issue under a different bug so I am marking this as a
duplicate of that problem.

- rhp


*** This bug has been marked as a duplicate of 17062 ***

	laurel
	Comment 13 • 25 years ago

Marking verified as duplicate (master bug already verified)