850 bytes, patch
|Details | Diff | Splinter Review|
346 bytes, text/html
233.15 KB, text/html
5.23 KB, text/plain
With build from 3/7 i don't get a lock, but it does take a very long time to finish loading, and when it does the TOC tree on the left is fully opened.
Assignee: rogerl → vidur
QA Contact: rginda → desale
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: Browser locks when rendering GIMP manual toc frame → Loading page is *really* slow (due to bad document.write() perf)
Whiteboard: [HAVE FIX]
Target Milestone: M14
Putting on PDT- radar for beta1. Please put a patch in the bug so we can do this after branch.
Whiteboard: [HAVE FIX] → [PDT-][HAVE FIX]
this is my results from the testcase (w/o patch): Net 4.7 ~12000 Moz m14 3020 IE 5.0 550 as you can see we're significantly better than 4.7, but no where near IE
The patch (or a similar patch) is checked in, we're doing much better now but I think there's still room for optimizing this, I won't close this bug yet, I'll move it to M17 for now...
Target Milestone: M15 → M17
Keywords: perf, testcase
Whiteboard: [PDT-][HAVE FIX] → [PDT-][HAVE FIX][TESTCASE]
Isn't this a dup of bug 23187?
Adding nsbeta2 to keywords.
Whiteboard: [PDT-][HAVE FIX][TESTCASE] → [HAVE FIX][TESTCASE]
Putting on [nsbeta2-] radar.
Whiteboard: [HAVE FIX][TESTCASE] → [nsbeta2-] [HAVE FIX][TESTCASE]
bug 23187 is a tracking/perf bug where as this bug covers a specific issue slowing down document.write() updating keywords & dependency
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M17 → Future
Nominating for nsbeta3 since it was in for nsbeta2 too.
Vidur says to give this to Jst.
Assignee: vidur → jst
Status: ASSIGNED → NEW
Depends on: 43902
Marking as [nsbeta3-] a number of bugs that were already marked Future (but not [nsbeta3-]) because the Netscape engineer the bug is assigned to is overburdened. If you disagree with this decision, please provide information about customer and user impact, but please do not clear the [nsbeta3-] unless you are reassigning the bug to yourself and committing to a fix within the nsbeta3 timeframe.
Whiteboard: [nsbeta2-] [HAVE FIX][TESTCASE] → [nsbeta2-][nsbeta3-][HAVE FIX][TESTCASE]
The speed of any real world document.write() currently also depends on bug 61842. Bug 61842 deals with a shocking slowdown due to parsing of script that contains HTML. In other words: Even if document.write() is fixed, performance will be not as good as expected. However, the dependency exists only wrt the test result and possibly not coding i.e. when Bug 61842 is fixed then the page this bug is concered with will render faster anyway.
Depends on: 61842
Removing old keywords and leaving as Futured for now.
Keywords: beta1, nsbeta2, nsbeta3, patch
Whiteboard: [nsbeta2-][nsbeta3-][HAVE FIX][TESTCASE]
The fixing of the dependencies has not fixed the real-world problem as the last comment attests- the GUM still is terribly slow, locking my browser for roughly 4 minutes when simply taking the material out of the cache! (IE 5.5 does the same in about 30 seconds, I haven't been able to reproduce a similar situation with NS 4.77.) On my PII 400 Win32: testcase computes 2630 on Moz .9.2, 1380 on NS 4.77, and 330 on IE 5.5, with fairly large standard deviations (about 20) on Moz and NS but practically none on IE. The correlation between the GUM time difference and the testcase time difference is extremely close- roughly 8x vs rather exactly 7.97x the IE time, so I think we can infer that the testcase accurately represents the problem without giving consideration to the (resolved) dependencies. This ought to be fixed for 1.0 (not that I have any authority to set that milestone). In my opinion, checking the patch in ASAP before the real push to 1.0 begins would be a Good Thing (TM).
The patch in this bug was checked in ages ago, and it did improve performace by an order of magnitude, the code relevant to this patch is long gone by now. Identifying and fixing the problems that remain more research and probably non-trivial changes to mozilla, I wouldn't expect much of that happening for mozilla1.0.
Some quick tests of mine (avg): Moz (2001070404): 1300 Net 4.7: 500 IE 5.5: 130 So yeah, this bug has come back with a vengance...
I just hit this site and had it not been that I'm used to Mozilla hanging for up to 1 minute on slow JS/DOM ops, I would as a user assume that the page crashes the browser.
*** Bug 90882 has been marked as a duplicate of this bug. ***
The fact that Moz M14 was beating NS 4.7 *without* the patch while Moz .9.2 and .9.3 lose to NS by taking almost all of twice the time NS 4.7 takes to do the same indicates to me a fairly major regression. I still think this is a 1.0 issue, but obviously the team has a lot on their platter and jst isn't very happy to take the issue, so it ought to be given some sort of marking for later so people remember it's a fairly major problem. You could put it as 1.0.1 or 1.1 tagged, that might do the job.
*** Bug 72107 has been marked as a duplicate of this bug. ***
I'll run a jprof of this when I get a chance (monday or earlier)
Created attachment 72501 [details] jprof of testcase With trunk from 2/28/02 roughly, Linux 7.2, dual-450 P3. Time is 1150ms. Nothing horribly obvious to rough inspection: 100 hits, 27% in nsHTMLDocument::Write, 22% in popping the Alert, 26% in XPC_WN_Helper_NewResolve() The rest is scattered around.
Created attachment 74529 [details] Flat profile from a PII400 machine I'm not very good with Venkman, but it seems to me data from something other than a dual-processor system is required. Here goes.
-that is not application/octet-stream, sorry I forgot to set the mime type-
20 days spent and (hopefully) less than a month before the 1.0 keyword and counting... If we're sure about this being a bug which is distributed across a bunch of different operators, it's probably a good idea to remove the 1.0+ keyword.
Attachment #74529 - Attachment mime type: application/octet-stream → text/plain
Ran the testcase in comment 5: IE 6 : 250 Opera 7 b2: 931 Moz 1.3a: 1103
Mass-reassigning bugs to email@example.com
Assignee: jst → dom_bugs
Status: ASSIGNED → NEW
The top culprit in a current jprof is the last-frame lookup when checking for :after generated content.
Depends on: 145425
15 years ago
Depends on: 233463
Just for fun, I ran the test case in comment #5 more than five years after this bug was posted on a Athlon64 3200+ running Windows XP. The results: IE 6.0: 65 ms Firefox 1.0.6: 140 ms Deerpark nightly: 95 ms The improvements in Deerpark suggest that this performance issue is eventually fixed.
Doing a bit of reminiscing I came back to this bug that I testcase'd 6 years ago. Testing on my WinXP machine with a testcase that does 10,000 writes I get: Firefox 126.96.36.199: 470 IE 6.0: 375 So we're a bit slower, but it's no longer the problem that it used to be. Marking as fixed.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
No specific bug / patch referenced as the fix. -> WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago → 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.