And now for a word from this evening's sheriff nazi: Three sleestack builds after the checkin, it looks like it can be safely said that new window time is up some 4%. Arguably it's been creeping up all day, but the biggest jump happened here. I'm fingering sgehani, who checked in a bunch of xul/css affecting the browser window. Samir, we have to make allowances for feature development of course. But I'll ask you to consider whether there's a better implementation, or perhaps to doublecheck your changes for inefficient xul. Spreading the love, I'm cc:ing everyone who contributed to the checkin that began about 6:00 PM PST on Tinderbox sleestack, http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1008119640&maxdate=1008122639
startup slowed from 6.27 -> 6.31 too.
This was posted on tinderbox for this checkin period. [email@example.com - 12/12 00:08] this step up in Txul times is due to law's checkin of how we report test results,same goes for other Txul numbers reporting in this checkin window.
Will test a current timeline, opt build with and without my changes and report back. I might add that I highly doubt my checkins (only one toolbarbutton added and some styling rules for it) could have made new window time increase by 4%.
Bill tells me the time increase reported in this bug happened during the period which we switched from reporting the minimum time in a series of tests to the median. Samir, if you're motivated to doublecheck don't let me stop you. But I think this is an invalid bug. I was ready to close it before you made that last comment.
danm, I'll be running tests for startup time anyways so we'll just use this bug. Thanks.
Never mind. I just saw bug 114914 for the startup bug. Marking invalid.