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.

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

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

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

And how is this dogfood bug going?

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

Bulk move rhp bugs to M11 for now

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

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.

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.

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.

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.

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.

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.

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.