445156 - MXR file listing output is significantly slower than LXR

Status: RESOLVED FIXED

(Webtools Graveyard :: MXR, defect)

Description

[Boris Zbarsky [:bzbarsky]]

MXR's output HTML for the actual file is a good bit bigger (so takes longer to download), and it uses some CSS constructs in a way that guarantees a O(N^2) load time for the page in page length.

By way of illustration, on my brand-new Macbook Pro, nsCSSFrameConstructor.cpp takes 56 seconds to load in MXR, with about a third of that time the browser being beachballed (one large hunk toward the end).  The same file takes 24 seconds to load in LXR, with the browser responsive at all times.

On my other (slower) machines, the difference is even more noticeable, of course.

I should note that I load this file a _lot_.  :(

Comment 1

[timeless]

Could you try again? I've pushed f98388c5973b which should help a bit.

I'm going to try to find some code to enable page caching, iirc i added such code to bonsai....

Comment 2

[Boris Zbarsky [:bzbarsky]]

As of right now, on a slightly faster machine:

MXR load: 152 seconds
MXR reload: 56 seconds
LXR load: 9 seconds
LXR reload: 2 seconds

Comment 3

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I looked at that changeset you pushed, and I'm not sure why it's supposed to help.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Scratch comment 3.  What timeless pushed eliminates the beachball at the end by not adding expensive style rules partway through the load.

With that fix, a "cached" (reload; I have no idea whether it's actually caching) MXR load is about 2x slower than a cached LXR load.  Uncached MXR loads are still slower by a bigger factor, not helped by the random delay between me clicking the link in the search results and the data starting to come in.  The delay seems to happen the first time I view a file (after it's been updated?  not sure) and ranges from about 10 seconds to about 2.5 minutes for nsCSSFrameConstructor.cpp.  During this time my browser is spinning the throbber and waiting for mxr to respond.  Is there something reasonably time-consuming that goes on at request time?

Comment 5

[timeless]

this should be fixed in changeset 111fe5934b28