[PERF] [DOGFOOD] Loading a message in Message Pane is slow



20 years ago
11 years ago


(Reporter: scottputterman, Assigned: mscott)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Perf] [PR1])



20 years ago
Starting off with rhp because I don't know where else to start.  We'll probably
need to Quantify this.

Displaying a message in the 3 Pane's message pane is pretty slow.


20 years ago
Severity: normal → major
Whiteboard: [Perf]

Comment 1

20 years ago
Perhaps Suresh can help with quantifying this.  Pls let him know if you need
assistance on this.


20 years ago
Target Milestone: M10

Comment 2

20 years ago
Most of the performance issues we have are due to temp file creation that is
taking the place of passing streams around. We have a plan to fix most of

- rhp


20 years ago
Blocks: 11091

Comment 3

20 years ago
Ok, after talking with mscott this weekend, we have a plan to address this. The
problem is inherent to the way we are loading the message (basically it gets
loaded 3 times...almost). So, the plan is that mscott and I will work out the
approach to improve this by August 6 and I plan to make the changes on my
flight to Mountain View this weekend.

mscott: how does this sound?

- rhp

Comment 4

20 years ago
And how is this dogfood bug going?

Comment 5

20 years ago
Very well...I have a the new envelope code working in my tree. I will be
checking it in when the tree opens.

- rhp


20 years ago
Blocks: 12176
No longer blocks: 11091

Comment 6

20 years ago
Bulk move rhp bugs to M11 for now


20 years ago
Whiteboard: [Perf] → [Perf] [PR1]

Comment 7

20 years ago
Need this for PR1, so I added a note to the Status Whiteboard


20 years ago
Assignee: rhp → mscott

Comment 8

20 years ago
I'm going to take over this bug since rhp is on sabattical.

The remaining things left per the newsgroup discussion Rich and I started:
1) Removing the temp file hack for message display
2) Insert some buffering in the mime emitter code. Right now, it converts line
by line and notifies the stream converter listener line by line that new data is
available. This is expensive because each notification involves creating a proxy
event and a thread crossing where it gets processed back in the UI thread.


20 years ago

Comment 9

20 years ago
I've landed the changes for news, mailbox and imap to remove our generation of
the "tempMessage.eml". They were in todays builds.

Before I can close this bug, the following things need to happen:
1) I need to do before and after performance metrics
2) I need to optimize the emitter code in mime to not generate OnDataAvailable
calls for each line of converted data. We need to batch the calls together.
Before I landed the tempMessage removal code, the mime converter was in a
different thread from layout so these calls were *really* expensive. Now, it is
in the same thread as layout so they aren't as expensive but we could still
benefit from batching them.

Comment 10

20 years ago
I just checked in code tonight to take care of (2). We now only signal the
converted mime data to the converter listener when we are done converting all
the data. We no longer signal that there is data available after each line.

On Deck: detailed platform specific measurements of before/after message display


20 years ago
Last Resolved: 20 years ago
Resolution: --- → FIXED

Comment 11

20 years ago
All of my known optimizations for message display are checked in. Making it
faster will require analysis with quantify.

Marking this bug as fixed. Performance metrics can come at a date after feature
complete milestone so I can try to get other stuff done.


20 years ago
No longer blocks: 12176


20 years ago

Comment 12

20 years ago
Linux Redhat 6.0 (1999-11-04-08 M11)
Mac (1999-11-04-08 M11)
Win_nt 4.0 (1999-11-04-08 M11)
Loading a message into Message pane takes about 2 seconds. Good job.

Comment 13

20 years ago
Fenella, can you mention the speed of your system and how much memory it has?
Also, mention the size of the msgs you're loading which are averaging 2 seconds.

Comment 14

20 years ago
Sure. But I think this is not consistent. I think it also depends on the network
too. I try it 2-3 more time, at the time I was verifying this bug. Its download
time was about 2 seconds on the same message I use.
The second time I tried, it took about 7-12 seconds.
The third time I tried it, the loading time is in between. here is the

Linux Redhat 6.0
HP X86, family 7
233 MHZ
128 MB Ram
Size of file:  13 KB takes 5 sec  (This tim
               89 KB takes 6 secs

Win_nt 4.0
Ram: 197
400 MHZ
Loading a 145 KB file takes 2-3 seconds
Loading a 92Kb file takes 1-2 seconds

Mac OS 8.6
144 MB Ram
300 MHZ
Unable to tell right now because it seems the network is not responding. Earlier
a file about 30 KB takes 2 seconds.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.