89872 - Performance Degradation in History window

Status: VERIFIED FIXED

(Core Graveyard :: History: Global, defect, P2)

Description

[Rajendra Shrestha]

Recent nightly builds seems to have a major performance degradation in the
History window. In my Red Hat Linux 7.1 box (P3 500 MHZ
226 MB RAM), I have 
both a 0.9.2 mozilla binary, and also an optimized CVS build. Comparing the two
builds shows that whereas the overall performance
of the browser has increased since 0.9.2, the History window has regressed.  I
was hoping that with the recent checkin
to use the outliner in History, its performance would increase, but the reverse
seems to have happened.

In particular, I have the following observations in the latest CVS builds:
1. If I resize the History window to make it larger, there is at least a second
delay  before the window gets repainted to the new size. In 0.9.2,
this painting is instantenous.
2. Once I have clicked on, say, "2 days ago", and I see the list of domains, I
need to double-click on the domain name for the pages 
under it to be expanded. With 0.9.2, I could just single-click on the domain
name for the pages under it to be expanded.
3. The time it takes for the tree to expand (both for the domain names and then
for the pages under the domain) has increased significantly.
With the same History set, the latest CVS builds now takes more than twice the
time to expand the tree than the 0.9.2 build.

Note that I am using an optimized CVS build to compare. Except for the History
windows, the rest of the browser seems a lot more snappy
than 0.9.2

Comment 1

[Blake Ross]

Yes, I notice this too.  Scrolling is also extremely slow and choppy.  However, 
once you switch to the group by none view, it's fine again -- as if we're 
needlessly trying to load the items in closed containers.

This isn't a problem with scrolling, say, lots of threaded newsgroup posts.  
Hyatt thinks it's something wrong with the rdf view, so -> waterson

Comment 2

[Chris Waterson]

hyatt is always right! The history data source is pretty slow when responding to
the queries made by nsXULTemplateBuilder::CheckContainer(), so I added a
front-end cache to store these values in the row. The first time you scroll a
new row onto the screen we're still a bit chunky, but afterwards things speed up.

Comment 3

[Chris Waterson]

Attachment: cache container type and state information with each row to avoid expensive lookups in RDF datasource

Comment 4

[Jan Varga [:janv]]

pretty cool patch
r=[e-mail]

Comment 5

[kinmoz]

Looks ok to me. rs=[e-mail]

Comment 6

[Chris Waterson]

Fix checked in.

Comment 7

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]