Closed Bug 23187 Opened 25 years ago Closed 19 years ago

document.write() is slow


(Core :: Layout, defect, P3)






(Reporter: ekrock, Assigned: roc)



(Keywords: perf, testcase)


(4 files)

On WinNT 4.0 SP3, I get the following stopwatch timing results for loading a
page whose body contains only a for loop that does 1000 document.write()

Nav4.7 - 2 sec
IE5.5beta - 1 sec
M12 1999122023 - 15 sec

The performance of document.write() statements in SCRIPTs in the body must be
improved. Will attach test case.
Whiteboard: [TESTCASE]
Marking [TESTCASE].
Assignee: troy → vidur
Vidur, I'll leave it to you to decide whether this is because of DOM, the
content model, or the lack of batching for layout. If it is the later, then this
will be a good test case for Nisheeth
Assignee: vidur → nisheeth
The latter is probably the biggest culprit. I'll let Nisheeth hold onto it as a
performance test.
Keywords: perf
Summary: [PERF] document.write() is slow → document.write() is slow
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Accepting bug and setting milestone to M14...
Target Milestone: M14
Vidur, I'm re-assigning this to you so that you can close it out once you 
checkin your content sink changes.
Assignee: nisheeth → vidur
It's much faster than it was, but is it fast enough? What say Krock? I checked 
in a fix to make it faster on 1/28/2000.
Moving this one along to a later milestone. I think the performance is much more 
reasonable now. The question is how good is good enough.
Target Milestone: M14 → M17
pardon me for bumping in here.  I dropped by the BugAThon pages and found this 
bug, and document.write() speed is an odd hobby of mine.

over on 
is some information about three tests I created about a year ago.  I altered the 
code slightly today so Mozilla M14 also runs it as it should.  I didn't shut 
down all applications before testing, but the result of a 150 table row test 
with the fastest output method (string concatenation directly in the write()) 

Communicator 4.72: 2800-2890ms
Mozilla M14: 2410-2530ms
IE 5.0: 550-600ms

if you guys are looking to improve the speed further than the current I'll 
happily run it through all 9 tests I have (three different write methods and 
three types of content) to see how it works out.
It's interesting to see that we're comparable to 4.72 in your test - my guess is 
that the fact that it's a table is relevant. I think we should continue to look 
at document.write speed, so more data would definitely be helpful. Thanks!
I ran Mozilla, IE5 and NC4.72 through all tests today.  I wrote a test report in 
HTML and uploaded it as an attachment.

Compared to NC4.72 the result is good for the first test, but Mozilla is 
considerably slower on the two other tests.  IE5 nails every test, in my 

What surprised me was the result of the second test when multiple 
document.write()s are used.  Mozilla suddenly spends 9 seconds, which is an 
speed decrease compared to test #1, while the other browsers have a speed 
increase.  M14 is still not as bad as IE4 though, which used 24 seconds on that 
test on a PII/266. :)

Overall Mozilla's performance is fair when the script is optimized for 
Depends on: 29805
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.
OS: Windows NT → All
Hardware: PC → All
Target Milestone: M17 → Future
The speed of any real world document.write() currently also depends on bug
61842, although the pure test case in THIS bug will probably not confirm this
because it uses a loop.
Bug 61842 deals with a shocking slowdown due to parsing of script that contains
In other words: Even if the performance problem that this test case uncovers is
solved, then any real world application bug that use this bug for tracking might
not necessarily be resolved.
Depends on: 61842
Johnny would like to hold on to this one.
Assignee: vidur → jst
what's the current status of this one?
Blocks: 118933
Keywords: mozilla1.3
Here is two new testcases with a timer for this bug :

Test1 does 10000 document writes on body onLoad without HTML formatting:

for (i=0; i<10000; i++)
{ document.write (i+" ");

Test2 does 10000 document writes on body onLoad *with* HTML formatting:

for (i=0; i<10000; i++)
	document.write ("<p>" + i + "</p>");

Setup : athlon 1700XP-256MB-WinXP-build 2002122808

Results :
        Test1     Test2
Moz     0.969     12.141
IE6     0.375      0.437

The document.write loop is about 3x slower than IE6 with test1 but is about 28x
slower with test2 !

I believe that this second test (similar to the original testcase) is mainly
displaying a major layout performance issue which may not be related to
Attached file Test1 testcase
Attached file test2 testcase
test2 becomes at least 3 times faster if the proposed patch in bug 145425 is
checked in (the one that makes us not do an O(N^2) walk over all the crap you're
Depends on: 145425
Keywords: mozilla1.3
Whiteboard: [TESTCASE]
bz, can you tell how much perf gain it will have on the testcase in bug 
151461 ?
None, as far as I can tell.
thx for checking!
then the perf bottleneck in bug 151461 is not document.write() - or?

Blocks: 203448
I would like to have a look at this. Stealing.
Assignee: jst → roc+moz
Priority: P3 → P2
Depends on: 242899
Some current testing, on PentiumM 1.5Ghz, WinXp, 1GB RAM (Thinkpad T40):
             IE6.0        Deerpark 20050720
Test1        0.40         0.45
Test2        0.46         0.75

So differences are becoming much less!
Actually, some re-testing (on 22/8/2005) results:
             IE6.0        Deerpark 20050817     Deerpark20050821
Test1        0.38         0.37                  0.38
Test2        0.73         0.78                  0.72 (!)

So, we are very very close, or can we just say there now the same?
* Deerpark20050821 has bug 243486 fixed (Lots of small document.write spend a
lot of time in cache code).
* IE6.0 was really: 6.0.2800.1106.xpsp2.05031-1526

Marking this one as FIXED (by bug 243486)
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.