Closed Bug 1608873 Opened 6 years ago Closed 5 years ago

hg.mozilla.org source link shouldn't be to the annotate view because it's very slow

Categories

(Socorro :: Webapp, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: asuth, Assigned: willkg)

Details

Attachments

(1 file)

I just clicked on a source link in crash-stats to https://hg.mozilla.org/mozilla-central/annotate/1536cf66a302811c1e302118e0d356c6c7545fab/xpcom/ds/PLDHashTable.cpp#l506 and it took on the order of a minute to load. When I clicked on https://hg.mozilla.org/releases/mozilla-esr68/annotate/f3d3cd51bc51c135310e49263d3bc1da8e1943e1/js/src/vm/Interpreter.cpp#l5209 network tools says it took 2.27 minutes before I got a 500 error that just said "Service Unavailable". I think that was just a proxy_pass timeout, as when I reloaded a little later, the page loaded in 1150ms suggesting the link was able to load successfully in the background and be cached. (We do something similar with searchfox.)

I suspect there's some kind of performance regression on hg.mozilla.org because this seems unusually slow, but in general it's also never been what I would call fast. So it seems more practical to link to the "file" version instead of "annotate" and let people click the annotate link there if they really want it.

When I click on the link, it comes right up. I don't think I've ever seen those links take more than 15 seconds to load.

Is it still happening for you today?

It seems a lot better today, yeah. The 2nd one said it took ~12.5 seconds per the network panel, but the tippy top of the page that says "Mozilla > releases" appeared like instantly, whereas yesterday it seemed like I got a completely white screen until almost the end.

And it's possible much of that time was just because it was a ~5400 line source file and the annotated version is 277K to the "file" version's 95K with most of that being a more complicated time which means more parsing/layout. That's probably also an argument for not defaulting to the annotated version. Although for people who are trying to source what is/isn't a recent change, annotate may be invaluable, they'd probably miss the annotated version. I don't know if crash-stats wants to grow a "pick your revision control tool". (It would be nice for people to be able to pick searchfox once we switch searchfox over to git-cinnabar so searchfox can understand the hg revisions directly.)

I'm okay if you close this, although I'll probably chime in again if hg.m.o regresses again in the future just as an squeaky wheel anecdotal datapoint. ;)

Grabbing this to look at soon.

Assignee: nobody → willkg
Status: NEW → ASSIGNED
Priority: -- → P3

Deployed in bug #1637009. Marking as FIXED.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #2)

Although for people who are trying to source what is/isn't a recent change, annotate may be invaluable, they'd probably miss the annotated version.

indeed, this change makes it a fair bit more difficult to look for causes to regressing crashes - i often click through numerous source links in the stack to see if there were recent changes, and now there are more steps to do so (click on annotate & manually scroll to the line in question or manually edit the url).

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: