Last Comment Bug 663255 - File/diff viewer is extremely computationally intensive and often yields unresponsive script warnings
: File/diff viewer is extremely computationally intensive and often yields unre...
Product: Graveyard
Classification: Graveyard
Component: Admin/Editor Tools (show other bugs)
: unspecified
: All All
: P3 normal
: 4.x (triaged)
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2011-06-09 15:19 PDT by Kris Maglione [:kmag]
Modified: 2016-02-04 14:47 PST (History)
4 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description Kris Maglione [:kmag] 2011-06-09 15:19:13 PDT
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110513 Firefox/6.0a1
Build Identifier: 

For especially large files, the file/diff viewer takes an extraordinary amount of time to become responsive, often yielding several unresponsive script dialogs. Oddly, pressing Stop Script often leaves a seemingly feature-complete view of the file. Even smaller files often show a significant lag on page change.

The lyz.js file in the following package is an especially pronounced example:

Reproducible: Always
Comment 1 Wil Clouser [:clouserw] 2011-06-09 17:04:40 PDT
Looks like we're using (which is an enormous JS file).

I'm happy to hear alternatives or improvements.
Comment 2 Kris Maglione [:kmag] 2011-06-09 17:13:05 PDT
I'm not sure that's the problem, because as far as I can tell, that only runs on diff pages and this also happens on non-diff pages. I initially thought it might be the syntax highlighting, but even stopping the script, everything appears to be highlighted properly. I'll have to see if I can get some more information out of Venkman.
Comment 3 Kris Maglione [:kmag] 2011-06-09 17:49:04 PDT
Huh. Interesting. According to Firebug, diff_main() seems to be the main culprit (along with quite a lot of time spent in jQuery).
Comment 4 Wil Clouser [:clouserw] 2011-06-10 13:27:36 PDT
The syntax highlighter we're using is

Are you saying it's our code or a libraries code that is being slow?
Comment 5 Kris Maglione [:kmag] 2011-06-10 13:45:16 PDT
I'm thinking that your first guess was right, given that the diff_main routine seems to be the main consumer, I just don't understand why that should be so. I can't really do much in the way of profiling on the production server, since all of the code there is compressed.

I does appear that something is wrong, though, given that the pages appear to display properly even after stopping the script.
Comment 6 Wil Clouser [:clouserw] 2011-06-10 13:46:43 PDT
scripts aren't compressed on
Comment 7 Kris Maglione [:kmag] 2011-06-10 13:48:20 PDT
Hm. I tried there. I suppose that it's because the standard jQuery and diff distributions are shipped compressed that I got such unsatisfactory profiling output.
Comment 8 Andy McKay [:andym] 2011-06-17 14:04:22 PDT

Is much faster, from bug 661947.

There's four parts: the diff (if relevant), the syntax highlighting, the line numbering, the diff bar.

In this case I sped up the line numbering an awful lot, that was the main problem with this file.
Comment 9 Wil Clouser [:clouserw] 2011-12-28 14:31:15 PST
I think this has been fixed up since this bug, especially with the validation results patch landing.  -> fixed
Comment 10 Kris Maglione [:kmag] 2011-12-28 14:34:08 PST
This is still a problem, although it's gotten somewhat better, I think. I still get unresponsive scripts several times a day.
Comment 11 Wil Clouser [:clouserw] 2011-12-28 14:55:50 PST
I tried the link above and it was super fast.  Do you have any add-ons installed slowing it down maybe?  (just a thought).  Anyone else have the problem?
Comment 12 Jorge Villalobos [:jorgev] 2011-12-28 15:04:15 PST
I almost never hit these warnings, but then again I don't review as much as Kris. Andrew, do you experience this problem often, or at all?
Comment 13 Kris Maglione [:kmag] 2011-12-28 15:25:57 PST
I'll provide a link the next time I see it. I think the file linked above was a special case.
Comment 14 Kris Maglione [:kmag] 2011-12-28 19:43:10 PST
This still causes problems for me:
Comment 15 Wil Clouser [:clouserw] 2011-12-28 19:46:06 PST
Page took a couple seconds to load, but no warnings for me.
Comment 16 Kris Maglione [:kmag] 2011-12-28 19:46:27 PST
I should note that this is with a test profile with only a few trivial add-ons installed.
Comment 17 Kris Maglione [:kmag] 2011-12-28 19:47:43 PST
For me it spun my CPU for 20 seconds before I got the unresponsive script warning.
Comment 18 Kris Maglione [:kmag] 2011-12-28 19:56:54 PST
I should also note, to put this into perspective, that I was at the editors meeting and mine was one of the more powerful computers there.
Comment 19 Kris Maglione [:kmag] 2011-12-28 20:50:06 PST
Here's another:

Although, a 12,000 line JS file... honestly...

We should probably just disable highlighting in those cases.
Comment 20 Andrew Williamson [:eviljeff] 2011-12-29 03:40:32 PST
(In reply to Jorge Villalobos [:jorgev] from comment #12)
> I almost never hit these warnings, but then again I don't review as much as
> Kris. Andrew, do you experience this problem often, or at all?

I used to get warnings on large files but it seems to be loading with only 2-3 second freeze now (on  There ideally shouldn't be any page/chrome freeze I suppose but its acceptable atm imo.
Comment 21 Jorge Villalobos [:jorgev] 2011-12-29 07:45:05 PST
(In reply to Kris Maglione [:kmag] from comment #14)
> This still causes problems for me:
> ih.js#top

Same as Wil, it took a couple of seconds, but loaded just fine. This is on my main profile, with a couple of heavy extensions installed.
Comment 22 Kris Maglione [:kmag] 2011-12-30 14:50:35 PST
Well, on my i5 MacBook Pro they load pretty fast. But that's not saying much. On my day-to-day machine, which I know outpaces what most other editors use, it's still an issue.
Comment 23 Jorge Villalobos [:jorgev] 2012-02-10 10:28:17 PST
Reclassifying editor bugs and changing to a new whiteboard flag. Spam, spam, spam, spam...

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