It looks like the form-state-in-content changes (bug 34297) caused a slight slowdown in page load performance (btek dropped from about 1450ms to 1480ms, and it looks like jst might've gotten about 10ms back later). Filing a bug to track the problem.

jrgm writes: Hey jst, bryner said you were looking at this. If it's any help, I did the A-B tests for page-loading on win2k, with a current trunk build as well, and also had a look at the linux numbers on btek. Maybe the names of the sites that showed the most change gives you somewhere to look. (Or at least, it shows the best pages to profile for changes; you can reach any of the test pages (minus javascript) from the bottom of the loader.pl form on http://cowtools/page-loader/loader.pl) biggest gainers from checkin at 11/01 23:40 Comparing average cached page load time in msec win2k (current trunk to a.m. mozilla build 11/01) current 11/01 % trunk mozilla delta --------------------------------------------------- www.yahoo.com 734 590 124% bugzilla.mozilla.org 973 815 119% www.spinner.com 1228 1091 113% www.mapquest.com 609 547 111% www.travelocity.com 1128 1033 109% espn.go.com 1078 1008 107% web.icq.com 1700 1604 106% www.ebay.com 900 857 105% www.tomshardware.com 1725 1660 104% www.google.com 204 197 103% hotwired.lycos.com 705 684 103% www.msnbc.com 687 667 103% slashdot.org 857 834 103% www.amazon.com 899 880 102% lxr.mozilla.org 1783 1751 102% linux (btek numbers from before and after checkin) after before % --------------------------------------------------- www.yahoo.com 935 743 126% www.mapquest.com 742 623 119% www.spinner.com 1528 1321 116% bugzilla.mozilla.org 1171 1018 115% www.travelocity.com 1411 1258 112% www.ebay.com 1042 966 108% espn.go.com 1323 1229 108% web.icq.com 2152 2003 107% www.msnbc.com 798 763 105% www.amazon.com 1072 1028 104% hotwired.lycos.com 852 822 104% www.apple.com 684 663 103% www.sun.com 574 557 103% John

Patch looks good, r=jkeiser with provision that you change PR_TRUE to PR_FALSE in the third hunk of nsHTMLOptionElement (in nsHTMLOptionElement::SetText).

See testcase for bug 60137 for another fun page load stress test.

Comment on attachment 56534 [details] [diff] [review] Don't flush like mad in the form control code now that the state is kept in the elements themselves. r=jkeiser

jonny, if this is not too risky, can you get this fix in for 0.9.6?

Yes, I'm planning on landing this for 096. Waterson, would you sr=?

No need to ensure you're getting a pointer argument here. A crash will do fine if someone can't call this method correctly. nsHTMLInputElement::GetTextLength(PRInt32* aTextLength) { - nsIFormControlFrame* formControlFrame = nsnull; - GetPrimaryFrame(this, formControlFrame, PR_TRUE, PR_FALSE); + NS_ENSURE_ARG_POINTER(aTextLength); Fix that and sr=waterson

Fix checked in, pageload times went down by ~25ms, which is about what the increase was when the form rewrite landed. Marking FIXED.

john can u please verify this bug for me. thanks

Yes, I noted the expected gainback in bug 108660 http://bugzilla.mozilla.org/attachment.cgi?id=56853&action=view