53417 - Create prototype XBL bindings to reduce bloat

Status: VERIFIED FIXED

(Core :: XBL, defect, P1)

Description

[David Hyatt]

Right now bindings are fairly heavyweight, since they hold onto a couple of 
strings.  These strings (and some other variables) could be held by prototype 
bindings.

This would be a hefty bloat reduction, especially in the thread pane.

Comment 1

[David Hyatt]

Nominating for nsbeta3.  It's easy to do, and it would be a good performance 
boost all across the product.

Comment 2

[Peter Trudelle]

Thread panes are gobbling up a MB every second or two, really need this.
nsbeta3+/p2

Comment 3

[selmer (gone)]

low risk and high payback!  pdtp1.

Comment 4

[David Hyatt]

fix in hand.  give me some kind of +, cap'n.

Comment 5

[Peter Trudelle]

You've got a plus, which is good for trunk landing (after owner & super 
review). This is not a branch candidate, nominating for rtm.

Comment 6

[Peter Trudelle]

mass-adding rtm keyword to all open nsbeta3+ xptoolkit bugs

Comment 7

[Peter Trudelle]

nsbeta3-, rtm+.  On bookmarks, scrolling time is decreased by 25%, decreases 
time to bring up a 2nd browser window by 15%, 1st browser window by 8%.  No 
metrics yet on space, but expect multiple-MB improvement scrolling through 
mail threads.

Comment 8

[Brendan Eich [:brendan]]

I reviewed the code fairly thoroughly, left a few to-do items that I'd like to
see tracked via XBL1.0 bugs, but didn't report a=[e-mail] in the bug.
Not sure that helps with getting this on the branch, but if code quality/review
is a concern, I would hope so!

/be

Comment 9

[Blake Ross]

So, the fix for this caused bug 54747, which will cause a crash in dialogs 
using the tab control -- of which there are many throughout the product.  How 
did this make it through the new, highly guarded checkin system?  And why was 
this reviewed and approved by the same person (wasn't the whole purpose of the 
new system to get lots of eyes on incoming code)?

Comment 10

[esther]

Update:  I ran the 2000-10-02-08 M18 mozilla build to scroll in the Messenger
thread window.  Then I ran the 2000-09-29 commercial branch, the mozilla build
(which has this fix) was a little faster.   Note: it's hard to tell the
difference on my linux system linux it's a 500mhz system.
Note:  I did crash as described in the bug 54747 with the mozilla trunk build.

Comment 11

[Chris Waterson]

esther: a good way to SWAG at the improvement is this. You'll need a stopwatch.
Start with a mail folder (or newsgroup) with a large number of messages. Hold
the "page down key" (or mouse-click in the scrollbar's page down area) and time
how long it takes for you to get from the top to the bottom of the folder.
Compare this number between the tip and branch builds. (Also, know that there
will be a significant difference between the *first* and subsequent times that
you scroll the folder, so be consistent and always measure "first scroll time".)

Comment 12

[Phil Peterson]

PDT marking [rtm++] assuming brendan's comments indicate a super review.

Comment 13

[John Morrison]

I did the test that waterson describes above: 

1) on a first run, clicking below the scrollbar to page down through 
   a 2000 message IMAP folder, the additional RAM (as measured in win2k
   task memory) to go through the entire threadPane dropped from ~40MB
   to ~28MB, which is a 30% decrease (although that is still a large number)

2) on a second pass, holding the scrollbarbutton down, to go from top to bottom
   the time to go through the whole 2000 messages dropped from 175s to 132s,
   which is ~25% quicker. The new number is actually approx. equal to Nav4.7
   on the same win2k box, although I expect that this test is strongly    
   influenced by the timers on the scroll operations.

Comment 14

[esther]

Chris I tried this with branch 9/29 and trunk 10/02 on linux.  Using your
scenario and a mail folder w/1685 msgs, branch time: 00:35:77  trunk time:
00:44:07  saving a little over 20%.

Comment 15

[David Hyatt]

Fixed on branch now as well as trunk.

Comment 16

[John Morrison]

verified fixed (by checkin and memory reductions).