If you are interested in performance, this is a good message to read.
Thread pane performance is one of the major problems affecting mailnews.
Specifically this affects folder loading, scrolling, sorting, and
deleting messages as well as other thread pane operations. We've always
known that a cause for this has been our usage of RDF and the way RDF
requires content to be built up when interacting with our datasources.
RDF needs to build up content for each message in a folder even if it's
not visible on the screen. In addition as you scroll it builds up even
more content as it fills in the information that wasn't part of the
initial data gathering that it does. This causes performance to be
slower than we'd like and it increases footprint. In the past we've
talked about using Random Access Enumerators so that RDF would only
build up content for items that are visible, but doing this looked to be
pretty hard and we weren't sure that it would actually achieve the gains
we desired. In addition, our usage of RDF sorting made it hard to
control views and sorting as much as we'd have liked to.
Recently David Hyatt came to us with a proposal to create an outliner
widget that would act as it did in 4.7x. Instead of building up content
through RDF, it would simply ask for the string to paint in each column
and all it would basically do is paint. He's now gotten to the point
where this concept is working and we've decided to go ahead and try to
use this. See http://www.mozilla.org/mailnews/performance/speed.html
for more info on this and on areas that are affected.
We expect there to be a huge benefit from doing this. We expect the
operations I've mentioned at the beginning to get much faster and
possibly approach 4.7 levels or even better. We will now have control
over our views and fixing our threading problems, doing navigation in
the standalone message window, and creating views in the 3 pane will all
now be easier. Finally, footprint should be decreased significantly.
What this means to the mail project
We are going to rewrite the thread pane to use this view. We aren't
planning to rewrite any of the other trees at the moment until we have
the thread pane working (with the exception of search because it
currently uses the thread pane and also needs to be made to use the new
widget)
In addition to adding the outliner to the UI we are porting over the
view classes that we used in 4.x so that mail will now maintain its own
views rather than using RDF (once again in the thread pane only).
We have scheduled out the work and we think it will take about two
months to get it up and running again. So that it doesn't affect the
current mail client, the work is being done on a branch
(MailNews_Performance_20010208_BRANCH)
Currently Scott MacGregor, Seth Spitzer, and David Bienvenu are working
on the branch setting up the new infrastructure and David Hyatt is
writing the outliner code. You can see what's been checked in during
the last week by using this link
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MailNews_Performance_20010208_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=week&mindate=&maxdate=&cvsroot=%2Fcvsroot>
.We welcome people to pull the branch and watch the progress (there's
currently a demo that shows scrolling of two columns and sorting and
it's really fast!) but ask for a couple of favors:
1. Please don't check into the branch.
2. If you use the branch, please do not file bugs. It's very much a
work in progress. When they are ready for feedback, it will be announced
and then bug filing can begin.
As they get farther into the rewrite more and more people will be
joining the effort and at that point more people can contribute to the
branch if authorized. At the moment we've scheduled this out and we
feel that 3 people are the right amount of people to do the initial
effort. We're not sure yet when the branch will be landed on the
trunk. It really depends on a combination of how long it takes to get
the mail window into a useable state and how much people are willing to
tolerate in a daily build. We'll cross that bridge when we get to the
point where we feel we have a useable thread pane.
In case you are wondering about the different tasks, here they are:
David Hyatt - outliner
1. Cell Painting (done)
2. Scrolling (done)
3. Selection
4. Image Display for icons
5. Keyboard navigation
6. Updating Views when invalidation called
7. Drag and Drop
8. Context Menus
9. Column Picker
Mailnews Team
Port the View Class over
Implement the thread view
Implement other views
Sorting
View Navigation
Command Infrastructure
Command Implementation
Drag and Drop
Context Menus
Search
FE Work to hook up the outliner to the mail views and mail ui including:
Displaying headers
Selection
Delete/Add
Notification Handling
Style Rules
Calling command and command updating
As I said, we think with the correct parallelization that this can be
done in 2 months with a month or 2 of bug fixes. A side effect of this
is that the Netscape Mailnews team will not be able to fix as many bugs
as we'd originally planned (some of you may have noticed the milestones
changing). We feel this is a worthwhile tradeoff to improve performance.
This is huge news for the mail project because we now have a great
chance of hitting thread pane performance goals that put us near the
performance of other mail clients. There will be periodic updates on
the newsgroup and of course in the status reports.
Scott
