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_. :(
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....
Assignee: bear → timeless
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
For what it's worth, I looked at that changeset you pushed, and I'm not sure why it's supposed to help.
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?
this should be fixed in changeset 111fe5934b28
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.