Confirming bug with Mozilla trunk binary 20020114xx on WinNT. Reassigning to DOM Level 0 - I stepped through this code via the JS Debugger, and the first two characters got visibly document.written(): for |a| = 33, 34. I had Mozilla side-by-side with the debugger, and I could actually see the two characters in the browser window. But no further document.writes were visible, even though I continued to traverse the loop step-by-step. I could "flush" the other characters by setting |a| to the upper bound, 10000. Then all the characters that had accumulated got document.written at once - about 30 characters or so by the time I did that. It just seems that Mozilla can't handle the load of document.writing 10,000 characters like this. IE6 handles it without any problem on my machine (WinNT4.0 (SP6), 500MHz CPU, 128 RAM).
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: pschwartau → desale
Mass-reassigning bugs to firstname.lastname@example.org
Assignee: jst → dom_bugs
This is essentially the same as the testcases in bug 23187 (and a jprof shows the same issues).
Depends on: 145425
Except this jprof also shows two O(N^2) searches in nsBlockFrame::AppendChild (because nsLineBox has to search for the last child and because it has to do IndexOf() when we call AddFrames; perhaps we should have a way to indicate that AddFrames is just appending?)
I think slow AppendChilds are also encountered when pasting lots of lines of text into editor.
No problems with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050903 Firefox/1.6a1 I think this is fixed.
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 marking WFM based comment 6 and my WFM does this mean blocking bug 145425 (which bz set) is also WFM? :)
Status: NEW → RESOLVED
Last Resolved: 13 years ago
QA Contact: desale → ian
Resolution: --- → WORKSFORME
You tell me. This was blocking that bug because it covered a specific testcase that showed perf issues in a profiler. Since you marked this worksforme I'm assuming you did some profiling and the issues are gone, right?
Not sure which you are suggesting I profile about but I did not do a profile on either. And I just realized my taskmgr was set at slow update, so perhaps my report is suspect. Still, cpu usage didn't go above 15%. What's a good profiler for windows?
Reopening. I don't care what your CPU usage is; the question is whether actual profiling shows any issues in the code. And on this testcase, it did last I checked and I don't recall the code being changed since. http://www.mozilla.org/performance/tools.html#profiling has some profiling tools listed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Created attachment 208672 [details] venkman profile of comment 0 script using FF 1.5 this is my first profile. I followed instructions at http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html#profiler using venkman from http://getahead.ltd.uk/ajax/venkman I have no skill to analyze or even say it is a good profile.
Wayne: This looks wfm, can you confirm ?
WFM 15.0a1 (2012-04-29)
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago → 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.