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)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: jmd, Assigned: bzbarsky)
References
()
Details
(Keywords: perf, Whiteboard: [nav+perf])
Attachments
(1 file)
(deleted),
text/html
|
Details |
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.
Assignee | ||
Comment 1•23 years ago
|
||
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?
Reporter | ||
Comment 2•23 years ago
|
||
Sorry, forgot to specify. Linux 0.9.1
Assignee | ||
Comment 4•23 years ago
|
||
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?
Reporter | ||
Comment 5•23 years ago
|
||
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
Assignee | ||
Comment 7•23 years ago
|
||
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.
Assignee | ||
Comment 9•23 years ago
|
||
because we need some hard profiling data...
Comment 10•23 years ago
|
||
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
Reporter | ||
Comment 11•23 years ago
|
||
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
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
on my cnn.com viewsource tests, nothing has changed, still ~3 seconds on my pII
400 with 256 RAM
Assignee | ||
Comment 14•23 years ago
|
||
futuring pending some info on what's eating the time here
Priority: -- → P5
Target Milestone: --- → Future
Comment 15•23 years ago
|
||
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
Assignee | ||
Comment 16•23 years ago
|
||
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
Comment 17•23 years ago
|
||
*** Bug 118167 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
Assignee | ||
Comment 19•23 years ago
|
||
That jprof is mostly showing the effects of bug 109428 -- we spend all our time
in GetPrimaryFrameFor, called from ContentAppended
Depends on: 109428
Comment 20•23 years ago
|
||
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.
Assignee | ||
Comment 21•23 years ago
|
||
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
Assignee | ||
Comment 22•23 years ago
|
||
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?
Comment 23•23 years ago
|
||
bzbarsky, interested in trying a one-entry cache in GPPF to see if it helps too?
-> bug 115049.
Assignee | ||
Comment 24•23 years ago
|
||
Um.. I'll give it a shot sometime when I have time, sure... Might take me a
while.
Assignee | ||
Comment 25•23 years ago
|
||
I tried a one-entry cache, and it doesn't seem to be affecting perf on any of
the pages that I tested...
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.
Assignee | ||
Comment 27•21 years ago
|
||
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.
Assignee | ||
Comment 28•21 years ago
|
||
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.
Description
•