109929 - try caching email address nodes in the to/cc toggle widgets

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Scott MacGregor]

Frame construction time is showing up as a hot spot for message display. I
believe a large portion of the construction time is happening because we create
new email-address widgets for the to and cc toggles every time we display a
message. For each address we create a new email address widget, set the right
properties on it, then add the widget to the long or short div for that header
field. When we view another message we remove all the elements in each div and
start again. 

We may be able to help reduce the time spent in frame construction by trying to
cache some of these email address widgets and just changing their value and
re-showing them again.

Comment 1

[Scott MacGregor]

.

Comment 2

[Scott MacGregor]

Attachment: implement email address node caching

initial pass at caching email address elements inside the multi email address
toggles. The logic is pretty complex so this patch may be buggy although I
don't see any problems right now. I'll run it for a day or two before landing.

Comment 3

[Scott MacGregor]

Comment on attachment 57892 [details] [diff] [review]
implement email address node caching

oops attached the wrong patch.

Comment 4

[Scott MacGregor]

Attachment: implement email address node caching

the right patch

Comment 5

[(not reading, please use [e-mail] instead)]

Comment on attachment 57894 [details] [diff] [review]
implement email address node caching

sr=sspitzer

very slick!

Comment 6

[Sean Su]

Comment on attachment 57894 [details] [diff] [review]
implement email address node caching

r=ssu

Comment 7

[Scott MacGregor]

fix checked in. Initial cache size = 3 addresses per widget.

Comment 8

[[e-mail] (gone - use [e-mail] instead)]

I tested the 27th build on my own time and found that we're 5.11 seconds to read
5 10KB messages in a local folder the 1st time, then 5.07 and 5.04 seconds each
consecutive time.  This brings us to 4.x parity! :-)

My numbers on http://www.mozilla.org/mailnews/win_performance_results.html for
the 23rd build are correct, but that build had something wrong with it, so I'll
be reposting.  

My messages each had 5 addresses and were 10kb in size each.

Verified FIXED.