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

VERIFIED FIXED in M11

Status

MailNews Core
Backend
P3
major
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: scottputterman, Assigned: Scott MacGregor)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Perf] [PR1])

(Reporter)

Description

19 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.

Updated

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

Comment 1

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

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M10

Comment 2

19 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
these.

- rhp
(Reporter)

Updated

19 years ago
Blocks: 11091

Comment 3

19 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

19 years ago
And how is this dogfood bug going?

Comment 5

19 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

Updated

19 years ago
Blocks: 12176
No longer blocks: 11091

Comment 6

19 years ago
Bulk move rhp bugs to M11 for now

Updated

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

Comment 7

19 years ago
Need this for PR1, so I added a note to the Status Whiteboard
(Assignee)

Updated

19 years ago
Assignee: rhp → mscott
Status: ASSIGNED → NEW
(Assignee)

Comment 8

19 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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 9

19 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.
(Assignee)

Comment 10

19 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
times.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

19 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.

Updated

19 years ago
No longer blocks: 12176

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 12

19 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

19 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.
Thanks.

Comment 14

19 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
statistics.

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.