Closed Bug 84707 Opened 23 years ago Closed 21 years ago

view source w/ syntax coloring very slow

Categories

(Core :: CSS Parsing and Computation, defect, P5)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: jmd, Assigned: bzbarsky)

References

()

Details

(Keywords: perf, Whiteboard: [nav+perf])

Attachments

(1 file)

Mozilla renders this URL normally in 20 seconds, including data transfer,
however, view source takes 4 and a half minutes (and it doesn't re-transfer it).
CPU usage is 100% during the time.

Without syntax coloring, view source loads in 27 seconds (again, no data
transfer involved), still longer then actually downloading and rendering the
document.
Looks like the problem is just a very big document with _lots_ of markup.  
View source with syntax highlighting is unlikely to get much faster for this 
unless our style system gets a lot faster.

Jeremy, what build are you using?
Sorry, forgot to specify. Linux 0.9.1
See also the comments in bug 74486.
bug 74486 basically implemented all the optimizations we can do to view-soure 
without completely changing the way view-source is done...  if you're using 
0.9.1 then big speedups of view-source particularly are unlikely.  How fast 
does 4.x show the source for this page?
4.75 does it in 2.5 seconds, all the way down to </html>. Mozilla 0.9.1 is 270
seconds, a 10,700% speed decrease. Even without coloring, it's still 11 times
slower. Disgusting!

At the very least, color needs to default to off, if this perf can't be improved
for 1.0.
can someone find out how long it takes parser to handle this page? or are all 
problems in layout/style?
Assignee: asa → jrgm
Keywords: perf
The parser is fairly quick.  If I create the <span> nodes and attach all their
attributes but don't actually insert them into the DOM, I get the unhighlighted
performance.  Not sure how valid that is as a test.  Some hard numbers really
would be great.  Is there a decent way I can actually time the various parts of
the process inside the code?  If there's any obvious slowness somewhere, it
would definitely be nice to hunt it down and kill it.

Jeremy, this pref _used_ to default to off for precisely the reasons you cite. 
This was deemed a bad idea since no perf work was being done on highlighting as
a result.  So the pref is staying on.  Vendors who package Mozilla can always
choose to default it to off in their default install.
Why is this assigned to jrgm?
Whiteboard: [nav+perf]
because we need some hard profiling data...
But, um, that document must have changed, because it is now a trivial ~500 byte
html document, and view source is equally trivial.

Anyways, I'm not really the right person to do this profiling (well, maybe at 
some point, but right now, no) So -> bzbarsky@mit.edu

You might look into some of the stuff that attinasi did to instrument 
the various phases of layout (on NT, if you have it). Look in 
http://lxr.mozilla.org/mozilla/source/tools/performance/layout/

(Of course, quantify (if you have it) or jprof on Linux are other ways to look 
for bottlenecks).
Assignee: jrgm → bzbarsky
Sorry, that document changed. I reposted the old one, updating URL...

Seems speed has increased for colored view source, and slightly decreased for
uncolored.

"very very very" -> "very", since the colored time was cut in half:

Uncolored:  33 s  Colored: 135 s
Linux 2001071608
Summary: view source w/ syntax coloring very very very slow → view source w/ syntax coloring very slow
This may very well be the style system; see bug 54542 for another example. 
Hyatt's recent (ok, a month or two ago) fixes to styles made a big difference;
on the order of 2x.  That's probably the speedup you saw in recent months.  Dave?

Changing component to Style System unless/until we get a profile on this.  I'm
leaving assignee (Boris) alone for now, until we have a culprit.
Component: Browser-General → Style System
on my cnn.com viewsource tests, nothing has changed, still ~3 seconds on my pII
400 with 256 RAM
Depends on: 97229
futuring pending some info on what's eating the time here
Priority: -- → P5
Target Milestone: --- → Future
I have noticed this bug too in a differnet web site.
Go to 
http://www.ynet.co.il
hit Ctrl+U --> View source take up to 50 sec'.
While the source is loaded the 
1.
Error: popup has no properties
Source File: chrome://messenger/content/mailNavigatorOverlay.xul
Line: 77
2.
Error: popup has no properties
Source File: chrome://editor/content/editorApplicationOverlay.js
Line: 82
3.
Error: popup has no properties
Source File: chrome://messenger/content/mailNavigatorOverlay.xul
Line: 77
4.
Error: popup has no properties
Source File: chrome://messenger/content/mailNavigatorOverlay.xul
Line: 77
5.
Error: newWin is not defined
Source File: chrome://communicator/content/contentAreaUtils.js
Line: 109
6.
Error: newWin is not defined
Source File: chrome://communicator/content/contentAreaUtils.js
Line: 109

I have
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011114
running on AMD Athlon K7 550Mhz
The js errors are irrelevant here.  (I have them fixed in my tree and view
source on that page stull sucks).  The issue you are seeing on that page is bug
86355 which is specific to bidi pages.
Depends on: 86355
*** Bug 118167 has been marked as a duplicate of this bug. ***
That jprof is mostly showing the effects of bug 109428 -- we spend all our time 
in GetPrimaryFrameFor, called from ContentAppended
Depends on: 109428
This (http://bugzilla.mozilla.org/attachment.cgi?id=63549&action=view) is one of
the clearest jprofs around.  70% direct hits in IndexOf(), all of them due to
your friend and mind, PresShell::GetPrimaryFrameFor().  Large flat documents are
bad to poor mozilla...

Related to bug 63890, bug 54542, and especially bug 109428
(PresShell::ContentAppended calls GPFF on every frame that it added).

Adding a few people associated with ContentAppended, etc.
Depends on: 129167
OK.  On the page in this bug, we now spend about 15 seconds to load the source.
 By comparison, NS4 on the same hardware spends 4.  This is _with_ syntax
highlighting.  Bug 129192 filed on the next-worst offender.
Depends on: 129192
So... now testing on the URL in this bug shows (with bug 129192 fixed):

NS4.x:  3.5 seconds (with highlighting)
Mozilla w/highlighting: 10 seconds
Mozilla without highlighting: 3 seconds

Jeremy, what are you seeing?
bzbarsky, interested in trying a one-entry cache in GPPF to see if it helps too?
-> bug 115049.
Um.. I'll give it a shot sometime when I have time, sure...  Might take me a
while.
I tried a one-entry cache, and it doesn't seem to be affecting perf on any of
the pages that I tested...
Depends on: 129640
Forcing line breaks in the view source parser could help as a workaround for the
layou issue. I made a large (almost 0.5 MB) HTML table with no newlines and view
source was unresponsive. Then I added a \n after each </tr> and view source
worked fine.
What did you think the "wrap long lines" option does, exactly?  ;)

The thing is, people expect to be able to get the "real" source, which includes
preserving all whitespace or lack thereof.
I'm going to go out on a limb and mark this fixed since the times have gone from
270/27 seconds to 10/3 seconds as a result of the fixes that have gone in.  At
this point, view-source profiles show nothing that looks like it could be easily
changed; further performance gains would really need to come from core gecko
arch changes.

Please feel free to file bugs on specific perf issues with view source, though.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: