I wonder if some of the work is duplicated (e.g. different windows have the same extension icon so we can just blit it once?). Alternatively, we could also do some of this work asynchronously so it doesn't block Chrome browser thread.

During the time Chrome was frozen, it was taking 150% CPU in activity monitor.

Wow, that's pretty terrifying. A large amount of time is spent in gfx::Image::ToNSImage(), so it seems like we're not doing a good job of caching extension icon images.

Alexei, did/could you try running with --disable-extensions to see if it makes an appreciable difference? (Or anyone else reading that can repro)

Haven't tried with --disable-extensions yet, but was able to verify that this is still an issue. Basically after killing Chrome and relaunching it when I had lots of windows and tabs, it's basically unusable for several minutes. When I profiled it, it shows that it takes 99% cpu time repainting BrowserActionCell's.

Deleted: sample_updated.txt 1.8 MB

sample_updated.txt 1.8 MB View Download

Sorry, the 99% above is not correct - it was 28% in the sample. I had the wrong aggregation selected (percent of parent).

Still, it's significant. I collected another sample later on in the same restore session and this one looks a bit different - with a lot of time spent in TabStripModel::NotifyIfActiveOrSelectionChanged() fired during session restore.

Deleted: sample_updated2.txt 2.4 MB

sample_updated2.txt 2.4 MB View Download

Here's a sample with --disable-extensions.

It's still slow. In this sample, it looks we're spending a lot of time in TabStripModel::NotifyIfActiveTabChanged() and others.

I think realistically there's a lot of opportunity for the restore scenario to be improved. There's lots of likely useless work being done during restore that causes Chrome to freeze and restore to be super slow.

Deleted: sample_no_extensions.txt 2.0 MB

sample_no_extensions.txt 2.0 MB View Download

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The issue with TabStripModel::NotifyIfActiveOrSelectionChanged is related to https://bugs.chromium.org/p/chromium/issues/detail?id=826287#c9. Selecting tabs is slow. Any code that attempts to sequentially select all tabs is going to be in for a very rough time.

Mac triage: assigning this to erikchen@.

I'm not sure to what extent we can/should fix this in the Cocoa browser, but the Views browser should not have this issue.

WontFix since this is an old issue with the Cocoa browser.