More information from Rohit:

The first jump is from 450ms to 475ms, and is one of:
18925 avi@chromium.org  Theme image support for the Mac.
18926 rohitrao@chromium.org  Adds a missing call to
TabContents::WasHidden() on Mac.

Then there's a lot of us messing around with the throbber, and
eventually we reverted everything to back where we started.

Second major jump is from 490ms to 505ms, and is probably:
19973 pinkerton@chromium.org  Don't install the RWHVMac into the view
hierarchy until everything has been properly sized.

Then we jump from 505ms to 520ms, and is probably:
20591 jrg@chromium.org  More bookmark bar changes.

I don't see a likely culprit for the drop between r20888 and r20901.

Keep in mind the reference build is far from a complete build, there are a lot of things 
it doesn't do, so as we've added more features (bookmarks, etc.) newer builds are doing 
work that the reference build doesn't do, so it's not a completely fair comparison.

Read Darin's email to chrome-team. When Chrome started on Windows we benchmarked it 
when it had no features, then as we added features we avoided regressing performance. 
That is the whole point of benchmarking early in the development process. This is why 
Chrome on Windows and Linux start up in < 200ms.

Agreed, but my point was what I checked in as a reference build throws a lot of 
messages on the floor, so we're not doing all the work we're supposed to do.  With 
those messages now being honored, we're drawing more, sizing windows correctly 
(larger) (but still not honoring the testing framework sizing request), actually drawing 
when told instead of throwing the requests out and waiting for idle (which in most cases 
never comes in the tests).  So I have no doubt there are things we can (and should) 
speed up, but we aren't very likely to maintain the exact same numbers, the added work 
will have some overhead.

(No comment was entered for this change.)

(No comment was entered for this change.)

I got 15% back for us in r23006 and r23196 from  bug 8044  and r23304 from  bug 
19094  and bug 16713.  Ts is now around 420ms, and is faster than the reference build.

Bouncing to Mark!
Bug seems ready to mark as fixed but I'll leave it open for something to track against.

Was Mark's fix for the regression? Do we understand what happened? If not, I wouldn't 
close this as fixed.

After the 70ms I found us last week, I'm happy to report that this week, some of our 
other talented engineers have been able to come up with another 70ms for your 
enjoyment.

 Bug 14823  r23722, 3.5% (15ms) improvement.
Something in [r23736, r23741], likely  bug 18352  r23741, 3% (12ms) improvement.
 Bug 18661  r23813, 11% (44ms) improvement.

Somewhere in 23853-57 we lost ~20ms. Haven't tracked it down.

(No comment was entered for this change.)

(No comment was entered for this change.)

This is a release blocker for Mac Beta.

We are deprecating the MacBeta milestone in favor of ReleaseBlock-Beta and 
a milestone.

Mac startup time seems now to have recovered from this specific incident.

I suggest filing specific individual bugs on remaining areas for performance 
improvement for Ts and Tntp. Feel free to close this one out.

--bug_count

(No comment was entered for this change.)

(No comment was entered for this change.)

Fixing a bulk edit. Looks like the search query was not correct.