Closed Bug 53417 Opened 23 years ago Closed 23 years ago

Create prototype XBL bindings to reduce bloat


(Core :: XBL, defect, P1)

Windows NT





(Reporter: hyatt, Assigned: hyatt)



(Whiteboard: [nsbeta3-][pdtp1][rtm++])

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 

This would be a hefty bloat reduction, especially in the thread pane.
Nominating for nsbeta3.  It's easy to do, and it would be a good performance 
boost all across the product.
Keywords: nsbeta3
Thread panes are gobbling up a MB every second or two, really need this.
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
low risk and high payback!  pdtp1.
Priority: P2 → P1
Summary: Create prototype bindings to reduce bloat → Create prototype XBL bindings to reduce bloat
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp1]
fix in hand.  give me some kind of +, cap'n.
Whiteboard: [nsbeta3+][pdtp1] → [nsbeta3+][pdtp1] FIX IN HAND
You've got a plus, which is good for trunk landing (after owner & super 
review). This is not a branch candidate, nominating for rtm.
Keywords: rtm
mass-adding rtm keyword to all open nsbeta3+ xptoolkit bugs
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.
Whiteboard: [nsbeta3+][pdtp1] FIX IN HAND → [nsbeta3-][pdtp1][rtm+]FIX IN HAND
Whiteboard: [nsbeta3-][pdtp1][rtm+]FIX IN HAND → [nsbeta3-][pdtp1][rtm+]FIXED ON TRUNK
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 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!

Depends on: 54747
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)?
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.
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".)
PDT marking [rtm++] assuming brendan's comments indicate a super review.
Whiteboard: [nsbeta3-][pdtp1][rtm+]FIXED ON TRUNK → [nsbeta3-][pdtp1][rtm++]FIXED ON TRUNK
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.
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%.
Fixed on branch now as well as trunk.
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta3-][pdtp1][rtm++]FIXED ON TRUNK → [nsbeta3-][pdtp1][rtm++]
verified fixed (by checkin and memory reductions).
You need to log in before you can comment on or make changes to this bug.