pawn jumped from average pageload times of 810ms to 950-960ms following the ThreadManager landing. Regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=Camino&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-10+09%3A00&maxdate=2006-05-10+15%3A00&cvsroot=%2Fcvsroot Tighter graph: http://build-graphs.mozilla.org/graph/graph.cgi?tbox=pawn.office.mozilla.org&testname=pageload&autoscale=1&size=&days=2&units=&ltype=&points=1&showpoint=2006:05:11:20:44:25,959&avg=1 No Mac tinderbox on FirefoxTrunk runs Tp; planetoid (SmTrunk) seems to have only jumped from about 369 ms to 373 ms in the same period (and has been hovering around 370 ms avg for the last 2 weeks), so this seems to be Camino-only. Ts took a hit, too; we hadn't been as consistent in the days immediately prior, due to the trunk state, I guess, but being generous, it looks like we jumped from about 2500 ms to about 2625 ms avg once things started to stabilize. http://build-graphs.mozilla.org/graph/query.cgi?tbox=pawn.office.mozilla.org&testname=startup&autoscale=1&size=&units=&ltype=&points=1&showpoint=2006%3A05%3A12%3A02%3A52%3A35%2C2634&avg=1&days=5 It's harder to do a comparison with other trees on Ts since it had just jumped a bunch on planetiod and atlantia prior to the landing (but was back on the way down due to the regression closure work), but Camino/pawn had been very stable around 2500 ms since about 20 April, so the 5% still seems noteworthy.

anyone else involved in that landing that should be cc'd? grr.

We should probably start by investigating the changes to widget/src/cocoa/. I haven't had a chance to build camino yet.

This might just be an effect of the new Gecko event processing model used for embedding apps.

-'ing. Would love to see some investigation, but can't block the release as this regression is a bit dated.

Does anyone believe that this bug is still fixable, or can we close it out as INCOMPLETE? I'm trying to clean up the regression list for the threadmanager landing a little bit.

(FWIW, see bug 337516 comment 26)