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: