Closed Bug 331364 Opened 20 years ago Closed 17 years ago

2% Tdhtml regression between March 7 and March 11

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: bzbarsky, Unassigned)

References

Details

If you're cced on this bug, you checked in during the time period when things regressed. Please look into this before even more time passes and it becomes even more impossible to deal with this. For more information, see http://build-graphs.mozilla.org/graph/query.cgi?tbox=luna.mozilla.org&testname=dhtml&autoscale=1&size=&units=&ltype=&points=&showpoint=2006%3A03%3A22%3A09%3A32%3A47%2C1568&avg=1&days=16 (and adjust the # of days to make sure to include March 7 and March 11 if you don't look at it today). It looks like there's no obvious single jump but rather three separate jumps -- one late on the 7th, one early on the 9th(?) and one on the 10th or 11th. The net result is a noticeable jump in Tdhtml. The checkin window looks to be http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-07+00&maxdate=2006-03-11+00&cvsroot=%2Fcvsroot or so.
For what it's worth, I think this is worth closing the tree for and will likely do just that tonight if there's no action on this bug.
http://wiki.mozilla.org/Performance:Tinderbox_Tests#Tdhtml:_DHTML_performance explains Tdhtml, for other folks to reference. (not me, rdf content sink is my baby in that time slot, just commenting as I comment anyway.)
I think the 7th one might be bug 234455 :( The problem with that bug is that it really fixes a lot of problems in DOM events and is the first phase of events clean up. ...trying to think how to speed up the event dispatching ... (which is now actually significantly faster than before if the DOM tree is very deep)
of my changes, the big one was backed out already, and the combobox change should not be affecting the DHTML tests (I don't recall them using comboboxes). Bug 328881 is a remote possibility. It shouldn't really affect anything ... should I test backing it out?
That does seem very unlikely, and possibly too late to be in the range to start with. I guess I'll try building gtk1 (which is what luna is) when I get back and seeing whether I can reproduce the slowdown there... If so, then we can just forget about this bug and file one on running DHTML tests on the platforms we're actually shipping. ;)
Er, ignore the second paragraph of comment 5, please. It was meant for a different bug. :( So I have no plans to investigate anything here myself.
aside from some mac changes, my changes were all cairo-only and the regression was on a linux tinderbox which doesn't have cairo on by default.
Between March 7 and March 11 I only checked in a whitespace cleanup patch in mail.
My changes were for the Extension Manager and shouldn't affect DHTML
This could have been me, i'm going to back out my patches and see if that has any effect on Tp
Tdhtml, not tp, right?
Backing out my changes caused a performance improvement of just under 0.5%, so that was possibly part of it, but there are other regressions too for sure.
> Backing out my changes caused a performance improvement of just under 0.5% Was there a particular test that showed a perf change? Or something more or less spread over the various tests? We were expecting GetBody to get a little slowed, as well as GetDocumentElement/GetRootContent; if some of the DHTML tests use those heavily maybe we can optimize a bit more somehow? And yes, there were several changes all adding up to about 2%, so about 0.5% each is about right....
It seems like scrolling speed took about a 7% hit. I'll put back everything but the GetRootContent stuff since that is likely the villain, and then look at that one separatly.
Actually, the scrolling slowdown doesn't seem to have been more then 2%. In any case, it's really hard to get a feel for any regressions on a particular test given that the noise is bigger then the regression.
I also landed code recently that calls GetBody more often than we used to (from nsGfxScrollFrame).
So looking at the 10ms jump in Tdhtml that happened around the time of the original root content changes, it looks to me like the biggest statistically signifacant jump was on the "diagball" test. That's also what I see I don't see obvious usage of document.body or anything in that testcase, though... So not sure what's going on. Maybe worth profiling that testcase? Unfortunately, the improvement from the backout seems to have been more scattered, with next to no effect on "diagball" and what looks like some impact on "replaceimages". Then again, "replaceimages" has changed a lot since March 8 (for the better!). "replaceimages" may be using root content via the document.images content list, possibly; certainly worth checking on.
I'm going through and marking old performance regression bugs as INCOMPLETE that are likely too old to be valid or get any traction on them. Please re-open if you have more information or can demonstrate the regression still exists.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.